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ABSTRACT 

The premise of this thesis is that many software 
application systems oerforra similar functions on a data 
object and contain a' significant operational intersection. 
An Integrated Apolication Software System (IASS) integrates 
the caoaoillties of the applications into one system. The 
purpose of this thesis is to evaluate the utility of the 
relational database model to conceptually integrate the text 
processing, relational database management, form generating, 
electronic mail, and electronic modeling aoolications . 

The conclusion of this study is that the relational 
database model can conceptually suoport the data 
representation and manipulation requirements of each 
application considered. Furthermore, the integrated system 
has potential capabilities that are not available in the 
non-integrated set of applications. 
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I. INTRODUCTION 



A, APPLICATION SOFTWARE PROBLEM 

The utilization of computers In many areas, such as 
personal computing or office and manufacturing automation. 
Is rapidly expanding. No longer Is their use being 
relegated to support personnel, but is spreading into the 
ranks of lower and middle level management. The majority of 
such users are non-computer professionals who are coming to 
depend on the computer to provide support to accomplisn 
their primary responsibilities. 

Over the past years, numerous software packaaes have 
been made available to support a broad spectrum of users in 
varying environments. Capabilities such as word processing. 



database 


management , 


modeling, form 


generation , 


and 


electronic 


mail have 


become essential. 


The ourpose 


of 



introducing the computer into an organization is to increase 
effectiveness and efficiency, While the performance of each 
support package is individually satisfactory, the manner in 
which they are presented to the user as a group is not. As 
illustrated in Figure 1,1, each support system is typically 
disjoint from all others, and the user is presented with 
different models, command vocabularies, and operating 
instructions. This non-lntecrated combination of 
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application software requires a special effort on the part 
of the user to learn a new system and remember it along with 
the other systems that are used. For instance, one simple 
task can be invoked in a different way in each system. 



1 




2 








3 


4 



Figure 1,1 - Disjoint Support systems. 



B, THE IASS OBJECTIVES 

What is needed to increase productivity is an Integrated 
system that combines the capabilities of the applications 
and presents the user with a single, yet easy, conceptual 
data model and vocabulary set. It is such a system tnat is 
called an Integrated Application Software system (IASS). The 
Objectives of such a system are; 

(1) Ensure a high degree of user friendliness and 
emphasize simplicity. 

(2) minimize the initial and acquired user skill level 
necessary to use the system. 

(3) Minimize the learnlnq time reauired to use the 
system. 
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(4) Present a logical distinction between each of the 
lASS's capabilities, but minimize explicit navigation 
between them, 

(5) Realize the largest functional intersection of the 
capabilities of each included application, 

(6) Develop a minimum set of primitive commands, 

(7) Minimize the dependence on programming in order to 
use the system, 

( 8 ) Embody the notion of software adaptivity whereby 
the user can learn a new application by learning only a 
small increment of new apollcatlon specific commands and 
functions, 

(9) Embody the notion of software reusability. New 
applications can be Implemented by adding a small increment 
of functions and commands which can be expressed in terms of 
existing IASS operations, 

while the IASS cannot be expected to completely 
Integrate tne features of each support pacKage, it can 
strive to maximize tne Intersection between them. Figure 1,2 
shows a simple illustration of an IASS in a Venn Diagram, 




Figure 1,2 - IASS Intersection, 
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The purpose of this thesis. Is to determine the utility of 
the relational database model as the Kernel of the IASS. 

C, IASS APPLICATIONS 

Five common softv/are apollcations were selected to be 
integrated; 

Cl) Text Processor 

(2) Relational Database Management System 

(3) Electronic Spread Sh^et 

(4) Forms Generator 

C5) Electronic Mail 

AS a non-integrated collection of application software, 
each is implemented to accomollsh a predefined set of 
operations on a specific file type. Data in a file is not 
directly sharable between apolications and neither are the 
commands to manipulate the data. Command vocabularies are 
usually "barodue" in that most of the operators are intended 
to exist as a matter of convenience to the user. However, 
too often it is a very small percentage of the overall 
vocabulary that is used most of the time. Users usually 
learn a subset of the vocabulary necessary to accomplish the 
essential functions of the application, and disregard the 
rest. It is the intersection of functions and vocabularies 
that the IAS3 suosumes and maKes the common system for all 
included applications. 



n 



Commercially available software application packages 
were reviewed to determine the nature of the logical file 
types and the essential functions. A detailed descriotlon 
of each of the application packages is included in 
Appendices A through I, 
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II 



IASS DATA OBJECT 



A. THE TABLE 

The logical file of any application system contains data 
which Is used by a specific set of application programs. 
The )cey to achieving an Integrateo Application Software 
System (IASS) which can support each logical file type Is to 
map each Into one data object. The data object chosen for 
the IASS is the table since it Is a natural method of 
organizing data and Is an easily understood object. Each 
column In the table represents one attribute of the file and 
each row represents an unique occurrence. The taoles 
Include columns which represent Key values to uniquely 
Identify eacn row. Any datum in a table can be accessed by 
specifying tha name of the table, the value of the key, and 
the name of the attribute containing the datum. In this 
thesis, rows will win also be referrea to as tuples or 
lines and columns as attributes or fields, A complete 
description of the table is given In Martin [Ref, 1). 

This chapter descrloes tne preliminary ceslgn of a set 
of tables which can support the data requirements of the 
IASS applications. 
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B. IASS TABLES 



In the IASS each application is a logical database 
consisting of a set of tables. There are three general 
classes of tables, data table, application directory, and 
data table schema. The data table represents the logical 
file of an application. The data tables are typed according 
to their primary use as, text, form text, database, spread 
sheet, and mall. Data table typing is done only to 
logically organize data tables which are used primarily by 
the same application programs. The IASS does not support 
strong data table typing. Being able to combine taoles of 
different types is an Important feature of the IASS, 

The application directory table contains descriptive and 
definitional data aoout the data tables in an application or 
logical dataoase. Each row in tne application directory 
table describes one data table and has a standard schema, 
Figure 2,1, ID is the primary key value of the application 
directory table, NAME is the unique name of the data table. 
COLUMNS is a list of column names in the data table. This 
list implicitly defines tne schema of the data table. 
ACCESS CONTROL defines the access privileges of various 
classes of system users to the taole, including read and 
write access and privileges to modify tne data taole schema. 
This data item also contains information concerning wnlch 
operations are allowed on the data taole. For instance, it 
may be decided that one dataoase data table cannot be joined 
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with a mall data table. TABLE POINTER points to the data 
table, DESCRIPTION is a literal description of the table, 
VIRTUAL indicates whether the data table is composed from 
other IASS data tables, CONDITION indicates how a virtual 
table is composed. For example, if the virtual data table 
was formed by a 3oln, that data would be stored in the 
CONDITION Column Of the abolicatlon directory. GLOBAL 
contains all the recurring Information which is applicable 
CO a data table as a whole, such as formatting, display mode 
(e.g, page or table),- access paths, etc. For each 
application, the schema of the application directory table 
can be auomented as required. 



ID 


NAME 


COLUMNS 


ACCESS 


TABLE 


VIRTUAL 








CONTROL 


POINTER 





CONDITION 


GLOBAL 


DES- 






CRIPTION 



Figure 2.1 - Apollcation Directory Table Schema 



The data table schema table 
column in the data tables, 
schema table Figure 2.2, is the 
ID is the primary Key of the 
data table has an. unique NAME. 



contains a 


row 


for 


each 


The schema of 


the 


data 


table 



same in each application, 
table. Each column in the a 
TYPE and wiDTH describe the 
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data type associated with the column and the maximum width 



of the data entry. 



ID 


NAME 


TYPE 


WIDTH 


SYNONYM 


TABLE 


ACCESS 














CONTROL 



Fiqure 2,2 - Data Table Schema Table 



Data typing supports the data integrity function of the 
underlying system, SYNONYM is the list of names cy which 
the column could be referred. This information is used to 
determine relationships that exist with otner data tables, 
possibly of a different type or allows tne same column to be 
referred to oy many different names depending on the context 
of its use. For example, in a personnel data table, the 
column name may be PNAME, This column could be referred to 
as PERSNAME, NAME, PERSON, etc. This column must oe used 
with caution. Its data may inadvertently change the access 
privileges of a user to a data item, TABLE Is the data 
tables the column occurs in, A query of the data table 
schema table can be done to determine the names of the 
tables the column is in to avoid searching througn an entire 
application directory, ACCESS CONTROL defines the 
privileges associated with eacn column tor a class of system 
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'1 




users Including read and write access and privileges to 



modify tne 
Figure 
that exist 



column definition, 

2,3 shows the relationships between 
in each application. 



the 



tables 



Application Directory 




Figure 2,3 - IASS Table Relationships 



This figure indicates that each row 
directory table is connected to a set 
table schema table and a data table, m 
a cross reference from a data table s 
directory table row. 



in tne application 
of rows in the data 
e dotted line shows 
chema taole row to a 
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Text Processor Tables 



a. Text Directory Table 

The text directory table contains a row for each 
text data table. The directory# Figure 2,4# has the 
standard application directory schema. Since the text data 
taoles can be output to a visual medium# each data table has 
a global print format. This data is stored in the GLOBAL 
columns or, if necessary# in a table accessed via tne data 
in the GLOBAL columns# and contains the page length, right 
and left margin# top and bottom margin# number of lines oer 
page# page header, page footer, tab spacing# and line 
spacing. 



ID 


NAME 


COLUMNS 


ACCESS 


TABLE 


VIRTUAL 








CONTROL 


POINTER 





CONDITION 


GLOBAL 


DES- 






CRIPTION 



Figure 2,4 - Text Directory Table Schema 

b. Text Data Table Scnema Table 

The text data table schema table. Figure 2,5# 
contains the predefined column set, ID and TEXT LINE, The 
ID is the primary Key of the text data table, TEXT LINE 

describes the TEXT LINE column in tne text data table. As 
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Figure 2,5 shows, the TEXT LINE can be aliased with the FORM 
LINE column in a form text data table or the BODY column in 
a mall data table. 



ID NAME TYPE WIDTH SYNONYM TABLE ACCESS 

CONTROL 



1 


ID 


in- 

teger 




NONE 


ALL 


read; all 
write; DBA 
modify; DBA 


2 


TEXT 

LINE- 


CHAR 




FORM 

LINE, 

BODY 


ALL 


read; all 
write: all 
modify; DBA 



Fioure 2,5 - Text Data Table Schema Table 



c. Text Data Table 

The text data table, Figure 2.6, is described 
by the COLUMNS and DESCRIPTION columns in tne text directory 
table. It contains data used to prepare a printed document 
or a computer program. The rows in a text taole are sorted 
on the ID column. Each row has an unique ID number wnich 
corresponds to the line number in the display. Although the 
user can refer to an ID numoer, an ID number cannot oe 
directly modified. The data in a TEXT LINE is unformatted. 
In a single line of text, there are two kinds of data that 
are recognized, the character string to be printed and 
special combinations of characters to oe executed. The 
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executable characters are specific to a text processor 
application program Ce.g, text formatter or compiler). 
Figure 2.6 shows the two <inds of data. Rows 1 and 2 
contain literal character strings to be printed. Row n 
contains a formatting command (page-break). 



ID 


TEXT line 


1 


NOW is the time 


2 


for all good men to 




Figure 2.6 - Text Data Table 



2 , Database Tables 

a. Database Directory Table 

The database directory table contains a row for 
each database data table. The database directory table. 
Figure 2,7, nas the standard application directory schema. 
The GLOBAL column contains data describing the display mode 
or printed format. 



ID 


NAME 


COLUMNS 


ACCESS 


TABLE 


VIRTUAL 








CONTROL 


pointer 





CONDITION 


GLOBAL 


DES- 






CRIPTION 



Figure 2.7 - Database Directory Table Schema 
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b. Database Data Table Schema Table 

The database data table schema table, Figure 
2.8, initially contains an entry only for the ID column. 
The ID is a Key in the database data table. As database 
data tables are defined, entries to the database data table 
schema table will have to be made. 



ID NAME TYPE WIDTH SYNONYM TABLE ACCESS 

CONTROL 



1 


ID 


INTEGER 




NOnE 


ALL 


read: all 














write: DBA 














modify: DBA 



Figure 2.8 - Database Data Table Schema Table 



c. Database Data Table 

Each database data table, Fioure 2.9, represents 
one entity, and is described by the COLUMNS and DESCRIPTION 
column in the database directory taole. The data in a 
aataoase data table is formatted. Each row is an unique 
occurrence of the entity. Tne columns of tne database data 
taole are the attributes of the entity. ID contains the 
display order of a row. This ordering does not imply tnat 
there is a canonical ordering of the entity. The ID can oe 
referred to out cannot be directly modified by the user. 
The other columns of tne database data table are not 
predefined. The database data table can oe directly viewed 
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at the screen by the user or printed, but may be reformatted 



based on the data In the GLOBAL column if necessary. 



ID ATTR-l ATTR-2 ATTR-n 




Figure 2.9 - Database Data Table 



3. Form Generator Tables 

a. Form Text Directory Table 

The form text directory table has the standard 
applications directory schema. Figure 2,10, Because the 
form is intended to be orlnted, each form contains a orint 
format which is defined by the data aoaregate named GLOBAL, 
This data aogreoate is the same as that contained in the 
text directory table orevlouslv described. 



ID 


NAME 


COLUMNS 


ACCESS 


TABLE 


VIRTUAL 








CONTROL 


POINTER 





CONDITION 


GLOBAL 


DES- 






CRIPTION 



Figure 2,10 - Form Text Directory Table Schema 
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b. Form Text Data Table Schema Table 

The form text data table schema table. Figure 
2.11 contains the predefined column set ID and FORM LINE. 
The ID is the primary Key of the form text data table, FORM 
LINE describes the FORM line column in the form text data 
table. Figure 2,11 shows that the FORM LINE column can be 
aliased with the TEXT LINE column in a text data table or 
the BODY column in mail data table. 



ID NAME type WIDTH SYNONYM TABLE ACCESS 

CONTROL 



1 


ID 


IN- 

TEGER 




NONE 


ALL 


read; all 
write: DBA 
modify; DBA 


2 


FORM 

LINE 


CHAR 




TEXT 

LINE, 

BODY 


ALL 


reao: all 
write: all 
modify: DBA 



Figure 2,11 - Form Text Data Taole Scnema Table 



c. Form Text Data Table 

A form is a repetitive document with blanKs to 
be filled in, A form can oe represented as a collection of 
rows contained in a table, as shown in Figure 2,12, and is 
described by tne COLUMNS and DESCRIPTION columns in the form 
text directory taoie. 
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ID 


FORM LINE 


1 


{NAME) 


2 


{ADDRESS) 


3 




4 


Dear {8. RELATION) 


5 


F0RM1.TXT 



Figure 2.12 - Form Text Table 



Each row of the table is sorted on the ID and corresponds to 
the same row in the form, Althougn the user can reference 
an ID number, it cannot be directly modified. The FORM 

LINE column, contains unformatted data. In addition to 
literal character strings which are printed, incluaing 
horizontal and vertical lines, it contains a special set of 
executable data, A special character comoination indicates 
whether the blanks in the form are to filled in by the user 
and stored in a table, or wnether the blanks are to be 
filled in from a table. This special set of data must oe 
known by the user as it is merely inserted as a combination 
of characters into the FORM LINE column. The view of tne 
form at design and modification time is exactly that of the 
form data table although it may be reformatted if necessary. 
Figure 2.12 contains an example of the data in 
the form text data table. The data in tne first FOKh LINE 
indicates that the printed value for the first row in the 
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printed form is to be retrieved from tne NAME column of the 
selected row of the associated database data table* Tne 
data in the fourth FORM LINE indicates that the printed- form 
is to contain the literal string 'Dear' followed by tne 
value from the RELATION column of table B of the associated 
database data table. The Information in row 4 also 
indicates that the associated taole is a join of two taoles 
each containing a column named RELATION. Row 5 Indicates 
that the body of tne form is a text data table named FQftMi. 

A form text data table is similar to a text 

table. They differ only in their data content and the way 

they are used. The data in the form t»“xt data table can be 

variables whose values are determined at print time. The 

0 

variables in a form do not have to be bound to a named data 
table or specific row in a data table and therefore can be 
re-used in the same or in many different aoolications , 

4 . Electronic Mail Tables 
a, Mall Directory Table 



ID 


NAME 


COLUMNS 


ACCESS 


TABLE 


VIRTUAL 








CONTROL 


POINTER 





CONDITION 


GLOBAL 


DES- 






CRIPTION 



Figure 2,l3 - Mail Directory Table Schema 
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The mail directory table contains a row for each 
mall table. The standard application directory schema does 
not have to be modified for the mail application. Figure 
2.13, The GLOBAL data Items contain the data to determine 
ownership of the mall data table and any other applicable 
Information , 

o. Mail Data Table Schema Table 



ID NAME TYPE WIDTH SYNONYM TABLE ACCESS* 

CONTROL 



1 


ID 


INTE 

-GER 




NOME 


ALL 


read: all 
write; DBA 
modify; DBA 


2 




CHAR 




NONE 


Af,L 


r-“ad; all 
write; all 
modify; DBA 


3 


TO 


CHAR 




NONE 


ALL 


read ; all 
write; all 
modify; DBA 


4 


COPY TO 


CHAR 




NONE 


ALL 


read; all 
write ; all 
modify: DBA 


5 


DATE 


CHAR 




NONE 


ALL 


read; all 
write ; all 
modify; DBA 




SUBJ 


CHAR 




SUB- 

JECT 


ALL 


read; all 
write; all 
modify; DBA 


7 


BODY 


CHAR 




TEXT LINE, 
FORM LINE 


ALL 


read; all 
write: all 
modify; DBA 



Figure 2.14 - Mall Data Table Schema Table 
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The mail data table schema table, Ficure 2.14, 
contains the system defined columns of a message. The ID Is 
the primary Key of each mall table. The other columns 
contain the data to denote the orlqlnator, reciolents, 
subject and the body of the messaqe. Figure 2.14 shows that 
the BODY can be synonymous with the TEXT LINE of a text data 
table or FORM LINE of a form text data table 
c. Nail Data Table 



ID FROM TO COPY TO DATE SU3J BODY 



1 


ME 


YOU 


THEW 


1/1 




MESSAGE 


2 


YOU 


ME 


THEW 


1/2 




MSG. TXT 


mm m 


m m 


m m 


0 m 


m « 


m m 


m 


n 















Figure 2.15 - ’^all Data Table 



Electronic mail is a utility wnich facilitates 
the excnanoe of textual messages between system users. A 
mall file contains a set of messaaes. The messaoe consists 
of data items which are read by the recipients. Tne mail 
table. Figure 2.15, is described by the CGLUNNS and 
DESCRIPTION columns in the mall directory table. Each row 
in the table corresponds to one message. Each messaqe 
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contains a header which is comprised of the FROM, TO, COPY 
TO, DATE, and SUBJECT Of the message. The BODY column can 
contain the entire message or the name of a text table. For 
example. Figure 2.15 shows that message 1 contains the 
entire message body. Message 2 contains the name of a text 
data table in the text directory table. The mall table can 
be directly viewed by the user as a summary of the messages 
but should be reformatted to read or edit a sinole message, 

5 . Electronic Spread Sheet Tables 
a. Soread Sheet Directory Table 

The soread sheet directory table contains a row 
for each spread sheet data table. The standard apoiication 
directory schema. Figure 2.1b, is used. 



ID 


NAME 


COLUMNS 


ACCESS 


TABLE 


VIRTUAL 








CONTROL 


POINTER 





CONHITION 


GLOBAL 


DES- 






CRIPTION 



Figure 2,16 - Soread Sheet Directory Table Schema 



The GLOBAL data items define the recalculation order, 
default format, and any other information aooiicable to the 
referenced spread sheet data table. 
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b. Spread Sheet Data Table Schema Table 

The spread sheet data table schema table, Figure 
2.17, contains the predefined columns of the spread sheet 
data table, ID is the primary icey of the spread sheet data 
table. The other columns contain the data to calculate the 
value of an entry position and construct the user view of 
the spread sheet data table. 



ID NAME TYPE WIDTH SYNONYM TABLE ACCESS 

CONTROL 



1 


ID 


in- 

teger 




NONE 


ALL 


read: all 
write; DBA 
modify; DBA 


2 


X 

INDEX 


CHAP 




NONE 


ALL 


read; all 
write; all 
modify; DBA 


3 


Y 

INDEX 


in- 

teger 




NONE 


ALL 


read: all 
write; all 
modify; DBA 


4 


FORMAT 


CHAR 




NONE 


ALL 


read; all 
write; all 
modify; DBA 


5 


VALUE 


CHAR 




NONE 


ALL 


read; all 
write; all 
modify; DBA 


6 


FUNC- 

TION 


CHAR 




NONE 


ALL 


read; all 
write; all 
modify; DBA 



Finure 2,17 • spread Sheet Data Table Schema Table 
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c. Spread Sheet Data Ta&le 

A spread sheet data table contains the formatted 
data to calculate the values of and display a numerical 
model. The spread sheet data table is described by the 
COLUMNS and DESCRIPTION columns in the soread sheet 
directory table, A spread sheet data table, Fiaure 2.1», is 
oolnted to by a TABLE POINTER in the soread sheet directory 
table. 



ID X Y FORMAT VALUE FUNCTION 



1 


A 


1 


INTEGER 

RIGHT 

3 


5 


5 


2 


A 


2 


INTEGER 

RIGHT 

3 


5 


5 















n 



A 



INTEGER 

RIGHT 

3 



10 



A 1 + A 2 



Figure 2,19 - Spread Sheet Data Table 



The spread sheet data table can be considered to be the 
tabular representation of the traditional spread sheet vle‘^, 
Figure 2,19, or, conversely, the traditional soread sheet 
view can be regarded as one dlsolay mode of the soread sheet 
data table. Each entry oosltion in the view is defined by 
one row in the spread sheet data table. 



30 



A P C D E F 

1 5 • 

2 5 

3 10 



Figure 2,19 - spread Sheet View 



The ID is the display order of the spread sheet 
data table but does not provide the ordering for the entry 



positions 


in the spread sheet view 


. The X 


and 


Y 


INDEX 


columns 


represent the relative 


Position 


of 


the 


entry 


position 


in the soread sheet view. 


The mapping 


of 


the 


X and 



Y indices to the display is contained in the GLOBAL column 
of the soread sheet directory table. The FORMAT column 
contains the data describing the display of the entry 
position, A numeric value of an entry oosltlon can be 
displayed as an integer, floating point, or dollar and cents 
number. The format information also indicates whether the 
values should be right or left justified and the width of 
the entry position in the display. The VALUE column 
contains the displav value of the FUNCTION column. The 
FUNCTION column contains an expression which is used to 
determine the value of the entry position. The expression 
could be tne typical constant, literal, or arithmetic tvpes, 
or could be a database auery, or a pointer to any other IASS 
data table. The operands of an expression can be any 
constant value or the value of another entry position in the 
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spread sheet. An operand value can also be an arithmetic, 
trioonometrlc , or some other predefined function, which u:an 
use the value of another entry position as a parameter. 
Using the value of another entry position as an operand in 
an expression is necessary to support dynamic modeling, l,e, 
when a chance Is made to one entry position. It is 
immediately reflected in the entire soread sheet view. As a 
matter of fact, the freedom to define value of one entry 
position in terms of any other entry position resulted in 
one data table structure and it also prevented us from using 
the database inteorlty enforcement mechanism for the soread 
sheet view. 
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Ill, CONCEPTUAL INTEGRATION 



A, OVERVIEW 

The main design objective of the Integrated Application 
Software System (IASS) Is to oresent the user with a slnole 
conceotual view of the system regardless of the context of 
Its use. From the user's perspective, there Is only one data 
object, the table. As was Indicated in Chapter 2, dependlna 
on the level of experience or Intent of the user, a 
translation may be required to reformat a data taole. This 
translation Is from table to table and therefore, the notion 
of a single data object is preserved. 

At the conceptual level of each application there is a 
common set of table operators and a set of application 
specific table operators. The common set of table operators 
represents the transportable Knowledge of the system as the 
user loolcally traverses between applications . The user must 
learn or be coonizant of only the application specific 
operations as the system use chanaes. 

By functionally categorizing each data manipulation 
operations on the logical file of the non-DBMS applications, 
an Intersection can be deduced. The intersection is 
comprised of operations to locate, insert, modify, delete, 
copy, and move data in a file. These operations can be 
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integrated at the conceptual level by a set of six basic 
IASS primitive table operators based on the relational 
algebra. This chapter demonstrates how the data 
manipulation operations of each selected application can be 
mapped into the conceptual level primitives. Although not 
the main Intent of this chapter, where appropriate, 
extensions to the typical operation are suggested. 

B, BASIC IASS PRIMITIVES 

The six basic IASS primitives wnlch can perform the 
operations in the functional intersection are IMSERT, 
MODIFY, DELETE, PROJECT, SELECT, and UNION. Each primitive 
is set theoretic in that the operands are tables and the 
results are tables, A table can contain any number of roivs. 
A special table, BLANK, is defined to be a row with all 
columns bianK except for the 10, A literal string, 
'literal', can stand for any character string in which it is 
contained. What follows is a description of the primitives. 
For this discussion the following conventions will be used: 

(1) The word table is synonymous with data table 

(2) Whenever two tables are used in an operation, 
table! and table2, table! will be the current table, 

(3) Column names will appear in uooer case, their value 
will be appear in lower case. 
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1 



Insert 



Given tablel, INSERT adds table2 at a specified 
location. The operator is denoted; 

INSERTClocatlon, table2, tablet) 

2 . Modify 

Given a table, ?^ODIFY changes the value of the 
columns in the rows of the table. The operator is denoted; 

MODIFY ( (COLUMN , column, new value)*’, table) 

where the 3-tuple (COLUMN, column, new value) describes the 
change by column name, present value, and the new value. 
The + Indicates that more than one column car. be modified by 
a single operation. If a chanae to a column value is to be 



made Irresoectlve 


of the present 


value , 




change 


any 


value in 


column 


NAME to 'JONES', that 


desire can 


be 


expressed 


by a special character, 


or wild 


card , 


Dlaced 


In 



the present value position of the 3-tuple, 

3 . Delete 

Given a table, DELETE deletes the set of rows from 
the table that satisfy a specified condition based on the 
column values. This operator is denoted; 

DELETE(condltlor , table) 

The ooerands of the conditional statement are literal or 
numeric constants, arithmetic expressions, or the column 
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values of the table. The operators of the conditional 
statement are the arithmetic comoarlson ooerators C<, >, 

St the loqlcal operators ( “» , a ), and the 

arithmetic operators (+, /). The delete operator also 

creates a table that contains the deleted rows. 

4. Project 

Given a table, a projection of the table is made by 
removlna some of its columns and/or rearranolno some of the 
remalnlnq columns. A projection of a table is denoted: 

PROJECTCcolumn list, table) 

where column list names the desired columns from the table, 

5 . Select 

Given a table, a selection returns the set of rows 
that satisfy a conditional statement based on the column 
values, A selection on the table is denoted : 

SELECT C conol tlon , table) 



6, Union 

Given two tables, tablel and table2, the union 
creates a table whose rows are in tablel or table2, or both. 
The union operation is denoted: 

uraON(table2, tablel) 

The schema of the resultant table will be the same as 
tablel. The columns In table2 whose content is not the same 
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as a column in tablel will not be in the resultant table. 
There are two differences between the union and Insert 
ooerators. First, union appends table2 to the bottom of 
table 1. Second, insert assumes that tables 1 and 2 are the 
same type, 

t 

C. REALIZATION OF LOGICAL OPERATIONS 

This section demonstrates that the data manipulation 
operations on the logical file in the functional 
intersection of each application can be expressed in terms 
of the conceptual level primitives. It will be assumed that 
the underlying system maintains the ID column as rows are 
moved in a table. Its resolution, therefore, will not be 
discussed, 

1 , Text Processor/Form Generator 

The command sets of several text Processors and the 
form generator facility of DBASE II and the ZIP form 
generator were reviewed, and it was found that the text 
processor set contained the set of form generator commands. 
Therefore, these applications will be discussed together, 
a. Locate 

Positioning the cursor typically comprises a 
laroe portion of the text processor and form generator 
operations, me cursor can be directed to a line number, 
relative distance from the current line, or to a substring. 
The result of bositlonlng the cursor can be considered to be 
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a line reference. Locating a row in the text or form text 
data table Is done by: 

SELECTCcondltlon, table) 

Uslnq the primitive, the text or form text data table can be 
browsed by contiguous lines (e.o ID ^ XI A ID ^ X2), or by 
line content Ce.g, TEXT or FORM DINE s 'substring'ACID < id 
+ 10 )). 

b. Insert 

Inserting a row into a text or form text data 
table at location ID is done by: 

INSERTCIO, BLANK, table) 

The same primitive can be used to Insert an entire data 
tabie2 into the current data tablel at location ID; 

INSERTCID, table2, tablel) 

c. Modify 

Inserting and deleting characters are 
functionally eaul valent in that they are modifications to 
the contents of a file. Assuming that the desired row is 
current, the operation to modify the row in a text or form 
text data table is; 

MODIFYCCTFXT or FORM LINE), 'old', 'new', table) 

The find and reolace ooeration is an extension of inserting 
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or deleting characters, with this operation, a row does not 
have to be previously selected. Also, a single change to a 
set of rows Identified by a conditional expression based on 
their column values can be done. The find and replace 
operation is done bv the expression; 

MODIFYCCTEXT or FORM LINE, 'old', 'new'), 
SELECT(condltion, table)) 

d. Delete 

Deleting a row or set of rows (block), from a 
text or form text data table is done by; 

DELETECconditlon, table) 

The condition can oe any function of the ID and/or TEXT or 
FORM LIME columns. This generalization enhances the typical 
text Processor or form generator operation since rows can be 
identified by number or content and a block does not have to 
be a contiguous set of rows, 

e. Copy 

Copying lines in a text or form text data table 
can be done by the expression; 

INSERT(ID,SELECT(condition, table), table) 

Any portion of a text or form text data tablel can be copied 
to or saved to another table2 by the expressions; 
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UNIONCSFLECKcondition, tabiei), table2) 

cr 

UNlONCOeLETECconditioTi, tablel), table2) 

The general nature of the orlmltlves enhance the tyoical 
text processor or form generator operation by allowing the 
lines to be Identified by content and not requiring that a 
block be contiguous. For examole, the statement; 

U,\-ION(SELECT(T£XT LI.N£ = 'A5C'A (ID < 10), 
taclel), tacle2) 

would copy to tacle2, any line in* tabiel witn ID less than 
10 and whose TEXT LIiVE column contains tne character 
substring ABC, 

f, '-love 

Moving rows or a block in a text or. form text 
data table to location 10 is done by tne expression; 

INSERTCID, DEL£TE(condltion, table), table) 

The condition can be any function of the ID and/or TEXT or 
FORM LIME columns. This generalization enhances the typical 
text processor or form generator operation which reouires 
that line numbers be known and a block of lines be 
contiguous , 

2 . Electronic ^ail 

The UNIX mail utility is an elaborate system which 
is closely coupled to the operating system. Viewed as a 
database taole, the complexity is reduced, A set of 
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essential mail operations were deduced from the UNIX mail 
system. 

a. Locate 

Displaying messages for reading or editing can 

be done by: 



SELECTCcondition, table) 

Using the orlmltlves, the message to oe displayed can be 
described by any condition of the columns of the mall data 
table. This would preclude the user from having to orowse 
the mall data table first to determine which messaaes mlaht 
be of interest and then listlno them oy number. 

A summary of the messaaes can be displayed by 
selecting a set of messaoes which satisfy a cond^ltion and 
then displaying the desired columns: 

PROJECTCcolumn list, SELECTCcondition, table)) 

By using the primitives, the user is not restricted to the 
predefined message summary, 
b. Insert 

A messaae can be created by appending a blank 
row into the mail data table and modifying its null 
contents : 

UNIONCBLANK, table) 

'<ODIFY( (COLUMN, i, 'new'), 

3ELECTC all columns = 0, table)) 
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Alternately, a message can be created at any location, ID, 
in the mall table by the expression: 

INSERTCID, BLANK, table) 

MODIFYC (COLUMN, 0 , 'new'), 

SELECTC all columns = 0 , table)) 

Regardless of the method used, the 3-tuple list In the 
modify ooerator contains a set of values for each column In 

the mall table except the ID, The change for each column is 

from null to the desired value suopiied by the user. 

Messages addressed to a user can be olcKed up 
from any mail data table2 by the expression: 

UNIONCDELETECTO = 'user', table2), table!) 

Messages can be picKed up from a mail data table2 that 

satisfy any soecifled condition bv the general expression: 

UNION(DELETE(condltlon, tabie2), table!) 

Finally, an entire mail table2 can be inserted into mail 

table! at location ID by: 

INSERTCID, table2, table!) 

c. Modify 

Assuming that a message has been selected, any 
field in the message can be edited by the operation; 

WQDIFY ( CCOLUMm , column, new value), table) 
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The same change can be made to several messages which 
satisfy a specified condition by slightly modifying the 
basic operation; 

MOOIFYC (COLUMN , column, new value), 
SELECKcondltlon, table)) 



d. Delete 

Messages can be deleted from a mail data table 
oased on any column condition bv the expression; 

OELETECcondltlon, table) 

Using the orimitives, a user is not restricted to a 
oredefined method of deleting messages. <*ith one operation, 
any set of messages can be identified and deleted. 

e. Copy 

There may oe an occasion when a cony of a 
message in a mail data table needs to be made, Copylno a 
message can be done by; 

UNlON(SELECT(conditlon, table), table) 

Messages can be copied or saved to another mail data table2 
by the expressions; 

UNlONCSELECTCconditlon, table!), table2) 

or 

UNlONCDELETECcondltlon, table!), table2) 
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Move 



Messages in a mail data taole are not ordered. 
They can be moved within a mail data table to location ID by 
the expression: 

INSERT (ID, DELETE (condition, table) , table) 

3 . Electronic spread Sheet 

As was noted in chaoter 2, the typical spread sheet 
view is not the spread sheet data table. However, data 
manipulation operations on the view can be translated into 
the operations on the spread sheet data table, 
a. Locate 

Entry positions in the spread sheet view are 
referenced by X and T oosition. As a result of the locate 
operation, the FUNCTION field is displayed. Locating entry 
position c, r in the table is done by the expression: 

PROJECTCFUNCTIOM , SELECT(X = c A Y = r, table)) 

The expression suggests that an entry oosition can be 
located by any other column in the spread sheet data table 
by the expression: 

PRQJECTCFUNCTTQN, SELECT ( cond i t ion , table)) 

A problem with VISICALC is that a model cannot be debugged 
very easily since the only one entry position can oe 
referenced at any time. The general nature of the primitive 
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operators enhances the debugolrg capability by allowing a 
set of entry positions to be located in the spread sheet 
data table by any condition of the column values. For 
example, all entry positions which have a VALUE greater than 
10 can be found by the single operation: 

SELECTCVALUE > 10, table) 

This same action using the VISICALC command set would 
reguire the user to locate the entry positions one-by-one. 
b. Insert 

One row in the spread sheet view is composed of 
C rows in the spread sheet data table CC = number of columns 
in the view), Insertina one row In the spread sheet view at 
r, is done by C iterations of the expressions: 

UNIONCBLAMK, table) 

MODIFYC ( (X, Jd, X ) , CY, 0, r) ) , 

SELECT CX = A Y = 0, table)) 

In the expression, x is an element of the column set (l..C>. 

One column in the soread sheet view is composed 
of R rows in the spread sheet data table CR = number of rows 
in the view). Inserting a column in the soread sheet view 
at d, is done by R iterations of the expressions: 

UNICNCBLANK, table) 

MODIFYC ( (X,0,d) , CY,0,y) ) , 

SELECTCX = J0AY =0, table)) 

In the expression, y is an element of the row set {1..R}. 
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Two Spread sheets can be apoended together to 



form one composite table by: 

UNlON(table2, taolel) 

Following a row or column insertion, further 
processing has to be done to move the successor rows or 
columns In tne spread sheet view. Moving rows or columns is 
discussed in subsection f. After the rows or columns are 
moved, the entry positions that use tne value of a moved 
entry position as an operand in the FUNCTIO^■ column must be 
found and modified. This process is described in suosection 
c. Finally, the modified FUNCTIONS must oe evaluated and 
the new entry position VALUE displayed, 
c, ’Modify 

A value or lanel entry operation in VISICALC is 
done to change the value of the FUNCTION column of the 
current entry position. The expression is: 

MOOIFYC (FUNCTION, function , new function), table) 

Movino an entry position (X = e, Y s p), in the 
spread sheet view by changing the X or Y value (X = c, Y = 
r) may reauire a subseouent modification to the FUN’CTIOn 
column of the entry positions that use e, d as an operand. 
The primitive expression to find and modify all of these 
dependent entry positions is; 
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MODIFYC (FUNCTION, 'ep' 
SELECTCFUNCTICN = 



'cr') , 

'ep', table)) 



The current entry position can be blanked by the 



expression ; 



MODIFY( (FUNCTION, function, 6 ), table) 

Clearina all entry Positions in the spread sheet view can be 
done as a soeclal case of the blankinc action previously 
described. Instead of the table beino a orevlously 

selected row, it Is in this case, the entire table; 

MODTFY( (FUNCTION , function, 0 ) , table) 

After modifylnc the FUNCTION column of an entry 
position, the FUNCTION must be evaluated and the new entry 
Dosltion VALUE displayed. 

The visiCALC format commands deal with the 
visual disDlay of entry positions, Formattlno an entry 
position reouires a modification to the FOPMAt column in the 
spread sheet data table. Chanaino the format of the current 
entry position Is done by: 

MODIFY( (FORMAT, format, new format), table) 

One format chance can be made to a set of entry positions 
which satisfy a specified condition by tne ooeratlon; 

MODIFY( (FORMAT, format, new format), 
SELFCT(conditlon, table)) 
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d. Delete 



One row from the spread sheet view can be 
deleted with the VISICAL.C command set. Since one row, r, In 
the view Is composed of c rows In the soread sheet data 
table, (C = total number of rows In the view) that many must 
be deleted from the spread sheet data table. The oberatlon 
is: 



DELETECY = r, table) 



Although 


the VISICALC 


command set does 


not 


allow mu 


Itlple 


rows to 


be deleted 


, the basic del 


ete 


ooeration 


can be 


modified 


to delete a 


block CYl through 


Y2) 


In the 


spread 



sheet view: 

DELETECY ^ YlA Y 4 : Y2, table) 

Deletlna a column is similar to deletlno a row. 
Since a column, c. In the spread sheet view is comoosed of R 
rows (R = number of rows In the view) In the soread sheet 
data table, that many are deleted by the slnole expression: 

DELETECX = c, table) 

This operation can be enhanced to allow the deletion of a 
set of columns (XI through X2): 



DELETECX ^ XIA X 4 : X2, table) 



4R 



Followlnq a row or column deletion. 



further 



processing Is needed on the table, in the view, a deletion 
requires that all rows and columns be moved to fill in the 
blank. Moving rows and columns is discussed in subsection 
£, After the rows or columns are moved, all of the 
dependent tuoles must be found and their FUNCTIONS modified 
to correspond to the new positions. Finally, the modified 
FUNCTIONS must be evaluated and the new entry position 
VALUES displayed, 
e. Copy 

Copying the current entry position CX = e, Y = 
o), to any other oositlon (X = c, Y = r), in the spread 
sheet view, can be done by the expression; 



MODIFYC (COLUMN, column, (e,o) .column) ,SELECT(X = cA 

Y = r, table)) 



If the destination entry oositlon (X = c, Y = r) is not 
found, a new tuple must be entered into the spread sheet 
table and its null contents modified: 



UNIONCBLANK, table) ^ 

MODIFYC (COLUMN, J3 , ( e , p ). column ) , SELECTCX = 0^ 

Y s js, table) ) 

For the entry position (X = c, Y = r), the 3-tuole list 

contains a chance for each column except X and Y, to the 
value of the same column in entry position at (X = e^ Y = p). 
Although order in the spread sheet data table is 
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insignificant, the entry position can be copied to a 
specified location by substituting the insert operator for 
the union in the previous expression: 

INSERTCID, BLANK, table) 

A column of height h, can be created in the 
view by maKlng h copies of the entry position at X = e Y = 
p. In the spread sheet data table, the operation can be 
done by selecting the rows with a Y value in the height 
ranoe (r through s) of the column, c, in the view, and 
making the same chance to the VALUE, FUNCTION, and format 
columns. The operation is: 

MODIFYC (COLUMN , column, (e,p) ,column)*",SELECTCX = cA 
CY ^ r A Y ^ s) , table) ) 

Copying a column of height h, can be done by 
making h calls to the copy one entry position process. On 
each call, the Y value for both the origin and target entry 
position is Incremented by one, 

Maklno n copies of one column can be done by 
making n calls to the copy one column process. On each 
call, the X value is changed. 

Copying a row of length l, can be done by making 
1 calls to the copy one entry position process. On each 
call, the X value for both origin and target entry position 
is Incremented by one. 
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Maklnq tn copies of a row could be done by maklna 
m calls to the copy one row process. On each call, the Y 
value would be chanaed. 

Any rectangular portion cf a soread sheet view 
in spread sheet tablel, (Y1 through Y2) by (X1 through X2), 
can be cooled to or saved to another spread sneet in soread 
sheet table2. This ooe ration is done by the exoresslon: 



UNIONCSELECTC (Y ^ Y1 A Y ^ Y2)A(X ^ XIAX s< X2), tablel), 
table2) 

or 

UNIONfOELETEC (Y ^ YlAY ^ Y2)A(X ^ XIAX < X2), tablel), 
table2 ) 



f. Move 

A row move, from r to s, in the soread sheet 
view can be done in the table by modifying the Y value of 
the C rows in the spread sheet data table. The expression 
is ; 



mcdifyCCY, r, s), SELECT(Y = r, table)) 

A set of rows (r through s) can be moved by the same 
expression with a different witn a different set of 
parameters : 

MGDIFYCCY, V, y - lr - Sl), 3ELECTCY T A '{ S S, table)) 

This expression is for the case where tne set of rows is 
moved up. To move the set of rows down, the new value in the 
3-tuple would nave to be modified to y + ir -sl. 
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Moving a column in the spread sheet view is done 



with the same primitive 
reiterated except to mention 
the original expressions wou 
After moving row 
positions have to be fou 
modified to reflect the 
modified FUNCTIONS must b 
position VALUE displayed in 



s. The process will 
that each occurrence of 
Id have to be changed to 
s or columnSf dependent 
nd and their FUNCTION 



new 


positions , 


Finally 


e 


evaluated and 


the ne 


the 


view . 





not 

Y 

X. 

e 

col 
w e 



be 

in 

ntry 

umns 

the 

ntry 
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IV. IASS EXTENSIBILITY 



A, COMBINING IASS TABLES 

From the review of the commercial application systems, 
it is clear that the non-DBMS applications selected for this 
study orovide functions to manipulate data In one looical 
file, Combinlno files, of the same type, can be done by 
appending files together or inserting one into another. As 
a result of these file combinations, however, no new 
relationships are developed nor can Information be deduced 
from the action. Using the relational database model as the 
common data model, there are a set of blnarv operators which 
can be used to combine tables to form new relationships and 
derive information. These ooerators UNION, SET DIFFERENCE, 
INTERSECTION, JOIN, and NATURAL JOIN are defined in Ullman 
CRef, 21, This chapter explores the semantics of combining 
the data tables by these ooerators. Speculation of this 
nature can result in numerous table combinations which could 
ootentiaily define a new apolication. This review is not 
Presumed to be exhaustive, but merely sugoests the 
meaningfulness of and potential uses for the lASS table 
combining operators. 
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8. INTRA TYPE COMBINATIONS 

This section considers the effect of combining data 
tables of the same type .by the operators SET DIFFERENCE, 
intersection, join, and NATURAL JOIN. The UNION operator 
will not be discussed since each application can use it to 
support an existing function, 

l • Text/Form 

Due to the similarities in the text and form tables, 
the semantics of the intra table combinations will be 
discussed together, 

a. Set Difference 

The set difference operator would be meaningful 
within the context of text orocesslng and form aeneratlna. 
It could be used In applications which reoulre a line-by- 
line comoar ison between two tables. For examole, It is 
often necessary to comoare two versions of the same computer 
program in the course of orooram development or two versions 
of the same form during design. By applylnc the set 
difference operator on two tables R and S, a listing of all 
the lines In R that are not duplicated in S would be 
returned , 

The set difference operator would also be useful 
in an application to extract entire sections from a table. 
Used in this way, the operator would represent the Inverse 
of the union or insertion operators to build a comoos ite 
table. From the composite table R, those same sections, S, 
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could be directly removed by performing a set difference. 
Similarly, the set difference could also be useful to remove 
lines from a table, R, that were contained in table, S. 

b. Intersection 

The intersection of two tables would be 
meaningful within the context of text processing or form 
generating. It could be used In applications reauirlng a 
line-by-line comparison or to match substring patterns of 

two tables to determine their similarities. For example, 

■ 

comparing versions of the same table to check their 
consistency could be done by taking the Intersection. This 
operator also suggests that two unrelated tables could be 
compared to determine their "closeness". The resultant 
table could be used to deduce "similarities between the two 
tables based on the fact that they contained identical 
lines, or used to selectively remove duplicate lines from 
either table, 

c. Join 

Joining two text tables or form text tables 
would be meaningful. It could be used in an application 
which required two tables to be in context simultaneously. 
For example, tables equHolned on their ID number would 
produce a split-screen effect to review and edit them 
side-by-side. This combination would be Particularly useful 
If the contents of one table was dependent on or related to 
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the contents o£ the other 



The same operation would be a 



method to produce a multi-columned table from two tables. 

Joining two tables would also be useful in 
applications which required a comparison of the lines of two 
tables. Because the join performs a cartesian product it 
would be unllXely that lines could be compared other than as 
to their equality. Since the join uses a selection 
operator, the join could determine equality by matchlm a 
line in R as a substrlnq in S or vice versa. An equijoln on 
the contents In two tables would produce a table which would 
list the lines in R next to the lines S that were equal. 
This could be used to determine the similarity between two 
tables with finer resolution than that available by taXinc 
the intersection, 

d. Natural Join 

To do a natural join of text tables or form 
tables would be meaningful, A natural join between two 
tables would produce similar results as those obtained by 
doing an intersection or an equijoln on the table contents. 
An apoii cation in which the natural join could be used would 
again be to produce a table based on the equality of lines 
contained in two seoarate tables. Instead of creating a 
table which contained a line from each taole in one row, the 
resultant table would contain only lines from one. As with 
the equijoln, the lines returned could be a substring match. 
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2 



Mall 



a. Set Difference 

The set difference operator would be ineanlngful 
In a mall utility. An apollcatlon In which the operation 
would be useful Is to eliminate duplicate messages from 
several mall tables, 

b. Intersection 

The Intersection of two mall tables would be 
meaningful. By doing an Intersection, duplicate messages 
could be located In several mail tables. This information 
could be used to selectively manage the message tables and 
control the number of message copies in the entire system. 

c. Join 

The join of two mall tables would be useful in a 
mall utility. It could be used in an anoilcatlon such as 
automatic readdressing. For examoie, consider the set of 
messages that have the same subject, A recipient could be 
in mall table R by virtue of the fact that it has received 
at least one message oertalnlng to the subject. This mail 
table In effect would reoresent a channel defined bv the 
common subject. As messages are received In the mall table 
S, an eouljoin on the SUBJECT column between mall table R 
and mail table S followed by a projection of R. header and 
S.Body would create a cooy of the new message for each 
recipient In mail table. 
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The join of two mall tables would also be 

meaningful in an ad hoc application to find messages in two 
mail tables whose fields have a specified relationship. For 
example, a Join could be done to return all of the messages 
in R and S such that they were from the same addressee but 
the messages in s were dated after the messages in R. 
d. Natural .Join 

A natural join on two mall tables would be 

meaningful. Since the BODY column of a message is textual, 
two messages could be considered to be equal if one was a 

substring match of the other, A natural join on two mail 

tables R and S would therefore, return all messages in R 
which had the same header as a message in S and whose body 
was either duoilcated, a subset of, or a superset of the 
body of the message in S, 

3 , Spread Sheet 

a. Set Difference 

The set difference operator would be meaningful 
in a spread sheet application. It could be used to compare 
two Instances of the same model. For example, if snread 
sheet R contained a model with one set of oarameters, and 
spread sheet S contained the same model with a different set 
of parameters, the set difference would produce a spread 
sheet view which showed each entry position in R that was 
different in S, 
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b. Intersection 



An intersection of two spread sheet tables would 
be meaninqful. It could be used to produce a soread sheet 
used to compare different instances of the same model. The 
resultant table in this application would show the entry 
positions that remained constant oiven a different set of 
parameters , 

c. Join 

The join of two spread sheet tables would be 
meaningful. If the spread sheets were tne same model with 
different parameters, an equljoin on the position fields 
would be a way to produce a table so that two spread sheets 
could be compared side-by-side. A process could be 
developed which could be used to toggle between the soread 
sheet in view, in this way, each spread sheet maintains it 
logical independence, 

A join between two soread sheet taoles would be 
the only way their contents could oe comoared by column 
relationships. For example, a join could be done to 
directly determine the differences between two instances of 
the same model or the same instance of a problem in two 
different models. The join on R and s such that the X and Y 
positions were the same but the VALUE in R was in a 
specified relationship to the VALUE in S would return a 
table which contained the entry oositlons in R and S which 
satisfied the condition. 
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d. Natural Join 



A natural join on two spread sheet tables would 

# 

produce the same effect as the intersection. 

C. INTER TYPE COMBINATIONS 



This section considers 


the 


effects 


of combining 


data 


taples of 


different types by 


the 


operators UNION 


, SET 


DIFFERENCE, 


INTERSECTION, 


JOIN, 


and 


NATURAL JOIN. 


Some 



table operations are not syntactically feasible on certain 
table types and therefore are not addressed. 

1 , Text 

a. Union 

The union between a text table and a form table 
would be meanincful. For example, the body of a letter can 
be kept In a text table. By unioning it to a form table 
containlno a letter head, a form letter would be created. 

The union between a text table and mall table 
would be meaningful. An application in which this ooeration 
would be useful to create a text table from the oodles of 
several messages in a mail data table. 

The union between a text table and a spread 
sheet table would be meaninoful. By appending a soread 
sheet table onto a text table, the FUNCTION column data 
could be Included in a text table, possibly to be sent to an 
individual In a letter. 
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The union between a text table and a database 



table would be meaningful. If a database table contained a 
textual column, for example a literal description of an 
object, the data in that column could be included in a text 
table. Conversely, a textual description about an object 
could be kept in a text table. By unioning the text table 
onto the database table, the data for the textual column 
would be provided. 

o. Set Difference 

The set difference between a text table and a 
form table would be meaningful. An application to remove 
text lines from a text table which were also in a form could 
use the set difference, A set difference between a text 
table and any of the other table types would not be 
syntactically meaninoful, 

c. Intersection 

The Intersection between a text table and a form 
table would be meaningful in an application to determine the 
text lines that were common in the tables. By this 
operation it could be determined if a form letter contained 
the a body stored in the text table. An intersection 
between a text table and any of the other table types would 
not be syntactically meaningful. 

d. Join 

A join between a text table and a form table 
would be meaningful, A text table can oe joined with a form 
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table on the ID fields which could be used to produce a form 
with a textual description. Either portion of this 
composite table could be separately edited. An eoul^oln on 
the lines of the text and form tables would return the lines 
which were common in both tables, 

• A join between a text table and a mall table 
would be meanlnoful. If the text table had one subject on 
each TEXT LINE, by doing an equljoln on the TEXT LINE and 
the message SUBJECT, a text table can be created which 
contains the message bodies pertaining to a set of subjects 
which are of interest. This could be a method of collating 
the messages from several system users concerning a 
particular subject into a single document, 

A join between a text table and a database table 
would be meaningful. For example, if a database table 
contained a textual column, the column in the database table 
could contain the ID of a text line. An equljoln on the 
database column and text line would supply the text for the 
database tuple. One text line could be contained in several 
of the database tuples and by maintaining one copy of the 
textual contents, all tuples will be assured of having the 
same textual column value. If the database table contained 
a mailing list, a join on the database table and the text 
table would be the procedure by which a copy of the text 
table could be made for each entry in the list. Another 
application in which a join would be meaningful between a 
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text table and database table is where the database contains 
a set of keywords or key ohrases. By dolnq an equljoln on 
the TEXT LINE and the keywords or key phrases, every line in 
the text table containing the keywords or key phrases would 
be returned. The same application also suggests that the 
combination could be used In . support of a word checking 
oroqram. Separate dictionaries can be maintained In a 
database table and joined with a text table. The resultant 
tables could be used to check spelling or to analyze a 
particular style of writing, 

A join between a text table and a spread sheet 
table would be meaningful, A narrative description about 
one model could be maintained In a text table. Since it Is 
common to store the same model with different oarameters In 
several spread sheets, one text table could be joined to the 
spread sheets by ID number to document the model. This 
would be useful to the user viewing the spread sheet table. 
To contain this additional Information In the view, would 
require an application specific orocess which would dlsolay 
the additional field, 

e. Natural Join 

The natural join between a text table and form 
text table would be meaningful since the column names are 
synonymous. It could be used to determine the lines of text 
contained in both tables. The resultant table would be the 
same as that returned by taking the Intersection, 
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2 • Forin 



a. Union 

The union between a form text table and a text 
table would be meaningful. An application in which this 
operation would be useful would be to generate a form letter 
as was addressed in subsection 1. The union between a form 
text table and a mall table would be meaningful. The body of 
a message could be a FORM LINE, By unioning the form table 
and the mall table, a form sent line-by-line through the 
mall facility could be regenerated, 

b. Set Difference 

The set difference between a form text table and 
text table would be meaningful. In a similar aopllcation as 
that discussed in subsection t, the operation could be 
useful to remove a set of text lines from a form, a set 
difference between a form text table and the other table 
tyoes is not syntactically feasible, 

c. Intersection 

The intersection between a form text table and a 
text table would be meaningful to determine the common lines 
of text between the two tables as was described in su beet ion 
1. An intersection between a form text table and the other 
table types is not syntactically feasible, 

d. Join 

A join between a form text table and text table 
would be meaningful in aopllcatlons discussed in subsection 
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1. A join between a form text table and a mail table would 
be meanlnqful, A user can sequence a FORf< LINES and name the 
form In the SUBJECT column and send a form llne»by-llne 
throuqh the mall facility. A form text table with one line 
can be created contalnlnq the form name. By an equljoln on 
the FORM LINE and SUBJECT columns, all of the FORM LINES 
could be collected from the mail table. The form can be 
resequenced by the data in the SUBJECT column of each 
messaqe. 

A join between a form text table and database 
table would be meanlnqful, A join on the ID numbers between 
a form text table and an associated database table would be 
useful to view the two tables simultaneously. The lines of 
each table in the joined table could also be edited 
Independently in this form, 

A join between a form text table and soread 
sheet table would be meanlnqful. Since the FUNCTION column 
could contain a reference to an entry in a database table, a 
form text table and spread sheet table could have a 
relationship throuqh a common database. An eouljoln on the 
FUNCTION column and FORM LINE would return the list of entry 
oositlons and form lines which contained the same database 
reference. In the view, the spread sheet and the filled out 
form could be displayed. This would be useful to show a 
spread sheet model and its parameter set In a form in one 
view , 
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e. Natural Join 



A natural join between a form text table and 
text table would be meanln«?ful .in the same application 
described in subsection 1. 

3. Mail 

a. Union 

The union between a mail table and text table 
would be meanlnoful. A message can be created by a union 
between a mail table and text table that contained a message 
body on one line. The message header can then be edited for 
the message created. Similarly, a text table of n lines 
could be unioned onto a mall table and sent to a svstem 
user. F®OM, TO, COPY TO, and DATE columns of n messages 
would be the same. The text table name and ID can be placed 
in the SUBJECT column to direct the recipient in the 
reconstruction of the text table. 

The union between the mall table and a database 
table containing a textual column is meaningful. The union 
would be useful to suPDly a message body fro.m the textual 
column. The header of the messaoe could then be edited. 
This would be a method to send data in a local database to 
any other user in the system. Another application for a 
umion between a database and mall table would be to generate 
a set of message headers in a database table. These headers 
could be unioned onto a mail table and then the BODY columns 
provided , 
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b. Join 



A join between a mail table and the form text 
table and text table is meaningful. For example, this 
operation can be used to send a text table or form text 
table to a system user through the mall facility, A set of 
message headers addressed to the same redolent contalnlno 
an ID In the BODY column, could be orepared in the mall 
table. By doing an eguijoln on the messaoe BODY and the 
text or form text ID columns, and removing the extraneous 
columns, a message containing each line of the form text or 
text table can be created, 

A join between a mail table and a database table 
would be meaningful. For example, a message could be 
addressed to a grouo of individuals recoonlzed by a single 
name. A database table could contain the mapoing from that 
sinole name to the individual names. An eguljoin between the 
TO column of the message and the column containing the 
aggregate name in the database would produce a table which 
contains a copy of the original message for each Individual 
Included in the group. This operation could also be used to 
generate a message. Having preoared the body of a message 
and using a standard subject line, a database table 
containing a set of headers including the subject, could be 
eouljoined with a mall table on the SUBJECT columns to 
produce the entire message. This message generation method 
is particularly useful in a situation where the standard 
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headers are always belnq revised. It Is also useful when one 
message needs to be sent to several different headers or 
several messages of the same subject need to be sent to the 
same header. 

Finally, a message can be created by joining a 
database table containing a set of message headers and a 
text table containing a message body on each line. By 
eauljolnlnq the two tables on the ID column, one heading 
would be joined to one body, A join on any other column in 
the header, and the TFXT LINE would join every header with 
every body. 

c. Natural Join 

The natural join between a mall table and 
database table would be meanlnoful. An apolicatlon in which 
a natural join would be useful would be to supoort routing 
of incoming messages. For example, it is often necessary to 
route messages to individuals based on the message subject. 
If a database were maintained which had fields for the 
subject and name of a person, the mall table could be 
naturally joined to this list. The result of the action 
would be a table which contained a copy of the message for 
each person. 

4 , Spread Sheet 
a. Union 

The union between a spread sheet table and a 
database table would be meaningful. This operation could be 
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useful In a situation where a spread sheet must contain 
standard entries. For example, a database table could be 
maintained with a subset of the spread sheet table columns 
Ce.o. X, Y, and FUNCTION), This database could be unioned 
onto a spread sheet table to boiler plate the soread sheet 
view, 

b. Join 

The join between a spread sheet table and 
database table would be meaninoful. For example, a database 
table could contain a set of values which are of special 
significance, A conditional join based on these values and 
the VALUE column In the spread sheet table would return all 
of the entry positions which satisfied the condition. 
Another apollcatlon in which this combination would be 
meaningful would be to store standard entry position 
definitions In a database table. An equljoln on the 
position columns would boiler plate the spread sheet. 
Finally, an application in which this combination would be 
meaningful is to store a set of parameters for a spread 
sheet table in a database containing columns for X, Y, and a 
vector containing the parameter set, 9y doing an eouljoln 
on the X and Y columns, and removing all of the columns 
except the X, Y, FORMAT, VALUE, and desired parameter 
column, the parameter set Is supplied to the model. 
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c 



Natural Join 



The natural Join between the spread sheet table 
and a database table would be meaningful. A database table 
could contain documentation with respect to each entry 
position in the spread sheet table. By doing a natural join 
on the X y columns, a spread sheet table could be documented 
tuple by tuple. This would especially be useful if there 
were Instances of the same model In separate soread sheet 
tables. For this application, the line documentation would 
only have to maintained in one database table, 

A spread sheet can be created from two database 
tables. Database table! could contain the X, Y, and FORh^AT 
columns representing a particular soread sheet format. 
Database table2 could contain the X, Y, VALUE, and FUNCTION 
columns representing a standard model. By a natural Join of 
the two tables, a spread sheet containing a standard model 
in a selected format would be oroduced. 
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V 



CONCLUSION 



A. FINDINGS 

Based on this study, it can be concluded that the 
relational database model can conceptually supoort the data 
representation and manipulation requirements of the selected 
IASS applications. At the conceptual level each loolcal 
file can be represented as a table and the common data 
manipulation functions of each application In Its 
traditional form can be expressed In terms of basic IASS 
primitives. In the IASS, higher level application specific 
functions can be defined in terms of the lower level 
primitives. For example, the COPY, move, and FIND AMD 
REPLACE functions can be expressed in terms of the primitive 
pairs, INSERT/SELFCT, INSERT/DELETE, and MODIFY/SELECT 
respectively. In addition to the intersection of commands 
and functions that exists between the IASS applications 
there exists an intersection of commands and functions 
between subsets of the applications. For example, 
formatting commands are applicable if a user is editino a 
text file, form, or message body. Also, aaoregate 
arithmetic functions are common to database and spread sheet 
applications. These Intersections further reduce the set of 
application specific commands and functions a user must 
Know , 
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The IASS also contains a set of four combining 
operators. When used to combine tables of the same type, 
these operators can be used to deduce information about data 
contained in two tables, and to create new tables from 
existing tables. In this way, the IASS enhances the basic 
capabilities of each of the non-DBMS aopllcatlons . 

By mapolna the loolcal file into one conceptual data 
object, data independence is achieved. Therefore, the full 
use of the specifically designed data tables can be realized 
by removing their semantic identity, A data table can be 
used by a logically different application or it can be 
combined with a different table type into a table which 



defines 


a 


new 


relationship. 


This n 


ew table can 


be created 


for an 


ad 


hoc 


application or 


for an 


application 


added to the 


IASS, 


The 


ability to combine 


data 


tables imparts to the 



IASS, capabilities which are not available from the set of 
disjoint applications. 
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directories and data table schemas into tables in a 
centrally maintained data dictionary/directory, 

After the conceptual level is re-evaluated, the next 
step in the project should be to design the physical level 
of the IASS and design the software to Implement the system. 
It is recommended that the first iteration of the 
implementation be a prototype consisting of the table data 
object and the ten IASS primitives, to evaluate the utility 
of the IASS to support the needs of a user in an actual 
operating environment. Subsequent iterations can Include 
the DBMS functions such as data integrity, security, and 
crash recovery. 

Concurrent with the Physical level and software design, 
the application specific command languages and processing 
programs can be designed. The text formatter, form orlnter, 
and spread sheet view generator can all be designed based on 
the data table definitions and the abstract interfaces of 
the primitives. 

Finally, it is recommended that the IASS be emulated on 
an existing relational DBMS (e.g, DBASE II), The reason for 
this is two-fold. First it would provide an available test 
bed which can be used to test concents which need to be 
resolved before the prototype system is delivered. Second, 
it could be used to determine the manner in which the IASS 
will handle the fundamental needs of the user before the 
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first prototype Is finished. It would therefore, be a way to 
Involve the user in the early design staaes of the IASS. 
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APPENDIX A: WORD STAR 



WORD STAR is a word processing program developed by 
Micro-Pro to combine the capabilities of a screen editor and 
an on-screen text formatter. The result is a very powerful 
text editor which displays the referenced file as It will 
appear on the printed oage, 

WORD STAR is primarily menu-driven. The commands which 
are presently valid are displayed in a menu, and are 
executed by Keystroke combinations. On-line information is 
available to the user concerning many other aspects of WORD 
STAR. The menu driven feature eases user initiation to WORD 
STAR and is part of the rielo facility. The level of help is 
selectable to match the users level of experience, and 
determines the extent to which the menus are displayed on 
the CRT. 

, WORD STAR is composed of a set of seven hierarchically 
organized menus or environments, as shown in Table A.i. The 
user enters word STAR in tne Mo-Flle environment. At this 
point there is no file in reference, the ooject granularity 
is the file, and the menu options include commands to: 
change the logged disk drive, set the automatic directory 
display feature (on/off), set the help level, print a file, 
rename a file, copy a file, delete a file, run a program, 
open a document file, and open a non-document file. 
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Table A,1 - WORD STAR Menu Hierarchy 



LEVEL 


MENU 


1 


NO File 


2 


Main Menu 


3 


a. Help 




b. On-Screen Format 




c. Print Control 




d. OuicX Edit 




e. Flle/BlocK 



WORD STAR recognizes two tyoes of files, "document” and 
"non-document". A document file can either be a text file 
processed by a word processor or a program run oy a 
computer. A non-document file is a special ouroose file 
which is used by another software product, and will not be 
discussed further. 

The on-screen editor and formatter are invo<ed by 
selecting the menu ootion to open a document file. This 
causes word STAR to enter the Main Menu environment with a 
specific file in reference. If the file oreviously existed 
it is made current, otherwise a new file is created and made 
current. On entering the Main Menu environment, a status 
line and a rule are Initialized. The status line contains 
information about the system - the name of the file, tne 
page within the file, the column and row number the cursor 
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is at, and the insertion mode (on/off). The rule indicates 
the right and left margin position as well as the tab 
positions. The Main Menu represents the basic file editing 
environment where the user win remain until it is decided 
to quit the current file and return to the No File Menu or 
the operating system. In any case, WORD STAR does not 
permit lateral movement between the sub-menus of the Main 
Menu, 

A useful feature word STAR employs is "word wrap”, with 
word wrap, the user does not have to insert carriage returns 
at the end of each line. As the text overruns the end of 
the line, word STAR automatically starts tne next line. In 
this way, the user merely inouts an entire biocK of text as 
a continuous ASCII character string, and leaves the 
formattino to the system. In the Main Menu, the user can 
edit the file in granularities of character, word, and line. 
Insertion is a "toggled” operation (on/off), where tne user 
is either in insert mode or overwrite mode. Any KeystroXe 
entered is either inserted in tne text at the cursor 
position, Shifting characters to the right to accommodate 
it, or overwrites the character at the cursor oosltion. To 
facilitate on-screen edltina, the Main '^enu contains 
commands to control cursor movement and to scroll the 
screen. It is possible to insert tabs or end-of-paragrapn 
markers. There is a "Find and Replace" command which can oe 
repeated any numoer of times. Deletions can be done on a 
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single character, a word, or an entire line. The Main Menu 
also contains options to select one of the five submenus. 

The Quick Editing environment supports editing on higher 
levels of abstraction of text objects than the Main Menu, 
There are additional cursor movement commands to give a 
wider range of control and granularity. As in the Main Menu 
environment, the user can scroll the display, but now it is 
continuous at nine user selectaole rates until stopoed oy 
command. Insertions are accomplished In tne same way as in 
the Main Menu environment, but deletions are possible on a 
wider range of objects. There is a feature to allow a 
command to be repeated at one of nine user selectaole rates, 
until stopped by command. 

The Block environment provides the user a set of 
oceratlons on a block of text, '■»ORD STAR considers an 
entire file to be a special case of a olock of text, Files 
can be saved by several menu options; save and resume the 
referenced file, save and quit to the operating system, save 
and exit the referenced file, and copy to another file. 
Files may also be renamed, deleted, printed, or quit without 
saving changes. To support these file operations, the Block 
Menu contains options to change the logged disk, and to turn 
the automatic directory listing on or off. In this 
capacity, the Block environment is used as a successor to 
the Main or Quick Editing environments after the cursor is 
positioned. Blocks in a file must be marked by the user. 
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As a deliiTilted aggregation of text, a block can be nioved 
within the same file. Copying blocks of text can either be 
within the referenced file or between the referenced file 
and an external file. Block copying between files are bi- 
directional, Copying a block to an external file entails 
overwriting an existing file or creating a new file. 
Copying a block from an external file entails moving the 
entire external file to the point in the text Indicated by 
the cursor. Any marked olock can also be deleted. As a 
precautionary measure, WORD STAR allows the user to hide 
block markers, and only blocks which are visioly marked can 
be deleted. In addition to a text block being organized 
into a continuous, unstructured string of text, word STAR 
supports a columnar organization. 

The previously described menus contain operations to 
create, edit, position the cursor, or output a text file. 
The format of the file, either as it is visually displayed 
or printed out, is defined by a set of formatting parameters 
associated with the file or by commands embedded in the 
file. The formatting parameters associated witn a file are 
initially set to default values and the set of embedded 
commands Is initially empty. 

Formatting in word STAR is primarily done on-screen witn 
the options contained in the On-Screen Menu, The on-screen 
formatting commands are those whose effects can oe visually 
displayed, and they are listed in Table A, 2. 
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Table A, 2 - WORD STAR On-Screen Formatting Commands, 

# 

1, Set left margin 

2, Set right margin 

3, Release margins 

4, Set and clear tabs 

5, Indent a paragraph 

6, Create a special rule 

7, Center text 

8, Set line spacing 



The On-Screen Menu also contains options in the form of 
(On/Off) toggles to control; word wrap, rule display, 
variable tabbing, hyphenation help, rioht margin 
justification, soft hyphen, print embedded control 
characters, and page brea< display. If an on-screen 
formatting operation needs to oe applied to the previous 
contents of the file, the applicable portion of the file 
must be reformatted. Furthermore, these formatting 
parameters are only temporarily applied when the file is 
referenced. Any subseouent reference to a file reguires 
that the on-screen formatting parameters be reset. 

WORD STAR combines into one menu, the Print Menu, all 
options Which create special printing effects not normally 
dlsplayable on a video screen. There are options to: bold 
face, double striice, underline, strike out, subscript, and 
superscript. Since the effects of these options cannot be 
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displayed on the video screen, a special character Is used 
to marK the affected area. Additional special printing 
effects are selectable through this menu on a one time 
basis: overprint a character, Indicate a non-break soace, 
and overprint a line. The Print Menu also contains options 
which control the printer during output. The user may embed 
commands in the text file to cause the printer to change 
pitch, or cause a pause to allow tne user to change the 
print element or ribbon. 

Printing can also be directed through the use of 
embedded dot commands. These commands are placed in the 
text file and appear as regular text on the display, but are 
not output to a printer and force WORO STAS to change a 
printing parameter at print time. Dot commands alter the 
default parameters word star uses to format the printed 
page. Table A, 3 provides a listing of these commands. 

Dot-commands may be placed anywhere In the text, but 
since they are static and tend to destroy the relationship 
between what is displayed and what is printed, they are 
usually Placed at the beginning of the text file. As with 
the options of tne Print Menu, dot-command actions must be 
supported by tne specific printer in use. 

The last menu to be described is the Help '*enu. Help is 
"on-line" in that it can be invoked at any time through the 
Main Menu, and is "dynamic" in that the level of help can be 
adjusted. The level will determine now much information is 



32 



displayed when an option is selected. The Help Menu options 
display information on: parapraph reforming, flags in the 
right-hand margin, dot and print commands, status line, 
ruler line, how to set margins and tabs, and how to move 
blocks of text. 



Table A, 3 - WORD STAR Dot Commands. 



1, set line height 

2, set page length 

3, set top margin 

4, Sec bottom margin 

5, Generate headers 

6, Generate footers 

7, set footer margin 

8, Reset page number 

9, Offset page from left side of printer 

10, Position page number 

11, Set character width 

12, Force a page break 

13, prevent a cage break 



WORD STAR is an excellent and very popular word 
processing program. The screen-oriented and on-line 
formatting features are different from other systems In that 
they are extremely easy to use. Once experience is gained 
with WORD STAR it is difficult to use line-oriented editors 
or off-line formatting systems. The on-line nelo facility 
makes word STAR easy to learn and user friendly. One aspect 
of WORD STAR that could be considered a disadvantage is the 
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larae command set. However/ belno menu-driven, the 
not normally used do not have to be memorized since 
always listed in the menu. 



commands 
they are 
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APPENDIX 01 VI 



"VI" is a t«xt editor used by the UNIX operating system 
and was created by the University of California at Ber<eiey, 
and Bell Laboratories* 

VI (visual) is a display oriented interactive text 
editor with a command vocabulary size of aoout ninety one. 
The user sees the CRT screen as a window into the text file 
and all editing operations are immediately visible. Line 
numbers are not displayed and have ho real use in vi, 
although it is posslole to find out the number for a line. 
For the saxe of protection the user does not actually edit 
the file, out a copy of it. At the completion of a session 
the user win indicate whether to Xeep the edited copy or 
the original. 

There are forty seven movement commands for control of 
the cursor, whicn is the editor's point of reference, and 
the screen display. Scope of movement is possible over 
file, screen, paragraph, section, sentence, line, word, and 
character sized units. Up to twenty six locations in tne 
file can be marXed for later return, or specific locations 
found that match a desired character string. Table B,1 
lists the cursor movement commands available in the VI 
system. Note that there is duplication, in that more than 
one command does the same thihg. 
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Table B,1 



VI Cursor Movement Commands 



1 . 

2 . 

3 . 

5 . 

6 . 

7 , 

8 . 

10 . 

11 . 

12 . 

13 . 

14 . 

15 . 

16 . 

17 . 

18 . 

19 . 

20 . 
21 . 
22 . 

23 . 

24 . 

25 . 

26 . 

27 . 

28 . 

29 . 

30 . 

31 . 

32 . 

33 . 

34 . 

35 . 

36 . 

37 . 

38 . 

39 . 

40 . 



Backward window 
Forward window 
Scroll down ♦ 

Scroll UP * 

Bacxspace one character ♦ 

Bacxspace a single character 
Bacxup a word 

Bacxup a word during insert 
BacXup tc beginning cf word 
Retreat to previous line ♦ 

Retreat to beginning of sentence 
Retreat to beginning of previous paragraph 
Retreat to previous section boundary 
Linefeed advance to next line 
Advance to first non-white space on next line 
next line, first white space 
next line, same column ♦ 
next character * 
beginning of word 
end of next word 
section boundary 
the next typed character 
beginning of next oaragraoh 
previous line * 
end of current line ♦ 
balancing parenthesis or brace 
cursor to last line on screen * 
cursor to middle of screen * 

word 



to 

to 

to 

to 

to 

to 

to 

to 



Advance 
Advance 
Advance 
Advance 
Advance 
Advance 
Advance 
Advance 
Move to 
Move CO 
Move to 
Moves 
Moves 

Move forward to beginning of 
Move forward to end of word 
Move to first non-white space 
Move to line number # ♦ 

Search for word ♦ 

Search forward for string ♦♦ 

Search backward for string * 

Search for next match ** 

Repeat last single character search 
Find a single character, backwards * 
Find a single character, forward * 
Reverse direction of previous find 



on current line 



* 
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Table B.l 



(Cent, ) 



41, Find first instance of next character 

42, Repeat the last search command ♦ 

43, Homes the cursor 

44, MarK the present position of the cursor ♦ 

45, Return to marked position * 

46, Redraw the screen 

47, Returns to orevlous context 



The operations of insertion, modification and deletion 
are supported by thirty commands that permit the user a 
varied level of object control. Items that are Inserted, 
modified or deleted are immediately updated on the screen to 
give the user a current view of the file status. The user 
also has the ability to undo the previous command if its 
effects were undesired. Most insertion and modification 
commands are structured so that they contihue to ooerate 
until the user Issues a command to terminate them. Normally 
during Insertion the user has control of format in that new 
lines are started by entering a carriage return. However 
there is an option that will let VI determine when to start 
a new line, based on line length, and let the user Just 
enter text as a continuous stream. Table B.2 lists the 
thirty edit commands. 

In order to use VI the user Issues the command "vi" 
followed by the name of the file to be edited, if this is a 
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new file, then the name will not be found in the directory 
and VI will create an emoty file. After entry, the user will 



issue cursor motion commands to maneuver through the 
and issue edit commands to change the contents of the 
There are no other modes or displays available in VI. 



Table 3.2 - VI Edit Command Summary 



1. Insert a number of spaces 

2. Insert nonprintable characters 

3. Insert "shlf twldth" blan< spaces 

4. Insert at the beginning of line 

5. Insert at end of line 

6. Insert before the cursor ** 

7. Insert after the cursor ** 

8. Insert new line below current line 
g. Insert new line above current line 

10. Insert text below current line 

11. Insert text aoove current line ** 

12. Delete last cnaracter 

13. Delete rest of the tex't on current line * 

14. Delete character oefore cursor 

15. Delete the following object 

16. Delete single cnaracter under cursor ** 

17. Repeat last command ♦♦ 

19. Join together lines ♦ 

19. Reoiace single character under cursor 

20. Reoiace characters at cursor 

21. Cnange the entire line 

22. Change single character 

23. Change the following object 

24. Cnange rest of the text on current line 

25. Undo last change to current buffer 

26. Restore current line to orevlous condition 

27. Yank following object into buffer * 

29. Yank a cooy of current line into buffer 

29, Repeat last text insertion 

30, Named buffer specification follows ♦ 



file, 

file. 



In addition to the two command categories already given 
there are additional commands of a miscellaneous nature. 
Table 9,3 lists these additional commands. 



Table 8,3 - Miscellaneous VI Commands, 



1, Print file status message 

2, Clear and redraw the screen 

3, Redraw the current "logical" screen 

4, Suspend or restart output 

5, Cancel oartially formed command 

6, Return to position in last edited file 

7, Reformat lines in buffer 

8, Indicate file and option manibulatlon 

9, Quit VI, enter line-oriented editor 



Some very basic formating commands for line length and 
indenting are directly available, A macro creation 
capability is present to allow tne user to create 
abbreviations for command strings. Table B,4 lists these 
formatting commands, VI makes no claim to supoorting a 
formatting package, since the file will be output in the 
same format the user entered it. For special formatted 
output a VI generated file must be processed by an off-line 
word processor, like "VROFF -ME" described in Apoendix (d). 

VI provides a high degree of support to the user for 
restructuring a file, or files. There are nine buffers 
available for storing deleted text, and twenty six ouffers 
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to use as temporary holding spaces while reorderinq and 
editing. The text can be taKen from other files and/or 
buffers, for use in the file currently being edited, if 
needed, previously deleted text from the current file can be 
recovered, and also other files. 



Table B.4 - VI Formatting Commands. 



1, Reformatting command 

2, Shift lines left one "shif twidth” 

3, Reindent lines 

4, Shift lines right one "sniftwidth" 

5, Prints current file contents 



"VI" is a good screen oriented editor and has a wide 
range of capabilities, however it has some drawbacVcs. 

(1) It has a poorly designed user Interface since the 
command vocabulary is very large and tne individual command 
strings are difficult to remember. There does not seem to 
have been much thought given to the design of the command 
vocabulary. 

(2) It takes a fairly long time to learn the vi system 
and gain functional use. An on-line tutorial program is 
used to help beginners, since it is hard to oecome familiar 
with it on their own. 
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(3) VI does not inspire user confidence in that it is 
too easy to accidentally enter some unknown command string, 
and there Is little correlation between what the user wants 
to do and the commandCs) that must be Issued, 

(4) From personal use, about thirty three commands were 
considered to be generally useful (marked by ♦ or ♦*), and 
only ten of these accounted for the greater majority of all 
operations (marked by The remaining vi commands were 



generally treated 


as 


"window dressing" 


oy all but the 


mo 


St 


sophlstl 


cated users. 












(5) 


There is 


no 


help 


facility, of 


any kind, provl 


ded 


by 


the VI 


system. 


At 


the 


very least, 


an on-line list 


ing 


Of 



commands should be provided. 
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APPENDIX C: EDIT 



EDIT is a text editor supported by the UNIX operating 
system, EDIT is a simplified version of another UNIX 
editor and contains a minimal set of operators. It is line 
oriented which means that the main object of EDIT is a line 
of text of some finite length, 

EDIT merely supports text file creation and modification 
operations. The user Inputs text into a file by lines, 
indicating the end of a line by a carriage return. A 
display of the file will show an ordered list of lines as 
they exist in the file. Ordering of lines is completely 
determined oy the system and although the user can use line 
numbers as a reference, the line number is not directly 
accessible to the user to change or set. Any display of 
text by EDIT is done by line. Substrings can be referenced 
within a line, or lines, A formatted output display by EDIT 
can only be achieved if the user directly Inputs the desired 
format line oy line, so processing of the contents of a 
line is done by EDIT, 

when invoked, EDIT sets aside a temporary copy of the 
referenced file in a working buffer. If the file does not 
already exist in the directory, then it is a new file and is 
created. The basic set of commands available to EDIT are 
listed in Table C.l. 
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Table C.l 



EDIT Command Summary 



1. 


Edit a file 








2. 


Specify a file 








3. 


Append lineCs) 








4. 


Insert line(s) 








5. 


Insert line(s) Into 


an 


external 


file 


6. 


Insert lineCs) from 


an 


external 


file 


7.- 


Delete lineCs) 








8. 


Copy lineCs) 








9. 


Move lineCs) 








10. 


Print lineCs) 








11. 


Show line number 








12, 


List lineCs) 








13. 


Substitute a string 








14. 


search for string 








15. 


Undo last command 








16. 


Make effect of command 


global 




17. 


Move cursor 

- forward 

- backward 








18. 


Quit 









Searching for a line has the effect of malclna the found 
line the current line. Any subsequent editina ooerations 
are done in relation to the current line. Lines can be 
found and displayed by line numbers, and ranges of lines can 
be specified. Lines can also be found and displayed for’^ard 
or backward, relative to the current line. A line can be 
found by any substring of its contents, but the entire 
substring must be contained in one line. Because of this 
deficiency a substring may not be locatable merely oecause 
it exists in the text file, when searching EDIT will move 
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forward or backward and will wrap around the buffer, 



so as 



to return to the starting line if tne target object Is not 
found. 

New lines can be appended before the current line, or 
inserted after it. The user Issues a command to specify that 
there are no more lines to add. Upon completion the current 
line is the last line added. Additions can also be made by 
moving or copying lines within the text file. 'Moving can be 
viewed as a combination of a deletion and an insertion. 3y 
specifying a range of lines to be changed, they are deleted 
and the system enters Insert mode for the user to add tne 
new lines. Additionally, insertions are possible from other 
text files. 

Modifying a line is done by substitutina a new string 
for an already existing target string on the line. If 
desired, the substitution can have global effect in tnat it 
will modify all occurrences of the target string on all 
lines , 

Deletion is usually accomplished by Indicating the line, 
or lines, to be deleted, A search command can be used with 
the deletion operation when the specific line numbers are 
not know, 

EDIT protects the user from making Inadvertent chances 
to a text file. The effects of the last executed command 
that effected the buffer can be reversed. Additionally, the 
effects of the editing session do not become oermanent 
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unless the user issues a comroand to make them permanent. At 

that point the edited copy, which is in the buffer, reolaces 

# 

the original file in the directory. Leaving EDIT without 
indicating to make the changes permanent is like the editing 
session never occurred, 

in addition to writing a whole buffer out to the 
directory, subparts can be written to another text file. 
This is done by specifying tne range of lines and the tile 
to be written to. 

The EDIT text editor is very basic which is both an 
advantage and a disadvantage . It has a minimal command set 
and therefore is easy to learn. The blgoest proolem is that 
it is llne-orientea. As such, modifications are done a line 
at a time, where each line is a separate entity. It does not 
treat the tile as a whole, but as a disjoint collection of 
lines. It imposes the idea of line numbers, wnich do not 
exist in the text file, in order to use the editor. There 
are fewer high level editing operations available, as 
compared to current screen-oriented editors, and they are 
limited to operating on lines and not tne text file as a 
whole, while capaole of producing satisfactory results, due 
to its line at a time limits, the operation oecomes tedious 
if the file is large, and/or there are. a lot of small 
chances which must be done. Given the advanced features of 
todays line-oriented editors, EDIT is a very archaic and 
frustratino way to create and modify a text file. 
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APPENDIX D: NROFF -ME 



"NROFF -ME" is a text processing facility for files that 
are created on the UNIX operating system. It was created by 
the University of California at Berkeley, and Bell 
Laboratories, "NROFF" is a program that accents an inout 
file prepared bv tne user and outputs a formatted paper to 
the user's design, "-me" is a macro package tnat enhances 
the capabilities of the "NROFF" program ny adding additional 
formatting abilities and commands. The input file consists 
of the actual text entered by the user» through some editor 
system, and a series of embedded NROFF -ME commands. 

There is a large vocabulary of "reouests", which are 
really dot-commands consisting of a period followed by a two 
letter string. The basic NROFF package supports seventeen 
categories of commands, and has a total of eighty seven 
commands. The -m£ package adds three categories and a total 
of sixty commands for a grand total of one hundred and forty 
seven commands. Table D.l lists the NROFF and -ME command 
categories, and the number of commands in each. 

NROFF -m£ uses thirteen predefined general variables and 
twenty three predefined read-only variables to support its 
processing needs. The user is provided with a macro 
facility to define new commands in terms of the basic set of 
commands and operations on the variables. This allows the 
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user to abbreviate a fairly long command stream Into a 
single command. 



Table D,1 - NRQFF and -ME Commands. 



COMMAND CATEGORY 


COMMANDS 

NROFF 


-m£ 


1, 


Font & Character Size Control 


7 


9 


2, 


Pace Control 


7 


0 


3, 


Text Filling, Adjusting & Centering 


6 


0 


4, 


Displays 


0 


22 


5, 


Vertical spacing 


7 


0 


6, 


Line Length & indenting 


3 


0 


7, 


Paragraphing 


0 


4 


9, 


Macros, Strings, Diversions, & Traps 


13 


0 


9, 


Number Registers 


3 


0 


10, 


Tabs, Leaders, & Fields 


4 


0 


11, 


InPutOutPut Conventions 


9 


0 


12, 


Hycnenatlon 


4 


0 


13, 


Titles 


3 


13 


14. 


Headings 


0 


b 


15. 


Line Numbering 


2 


0 


16. 


Conditional Input 


8 


0 


17. 


Environment Switching 


1 


0 


18. 


Standard Input Insertions 


2 


0 


19, 


InputOutPut File Switching 


3 


0 


20. 


Miscellaneous 


5 


6 




TOTAL 


87 


60 



NROFF -ME Is a good word processing system and it can 
produce some complex formatting actions. However, It does 
suffer from some drawbacks, 

(1) Since the file is first created by the text editor 
and then run by MRCFF, the user has a significant delay in 
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determining If the desired format was achieved. 

(2) In addition to depending on the text editor. NROFF 
must depend on other programs to preprocess the text file 
before NROFF can handle it for specialized reauests. Two 
examples of preprocessors are packages to handle tables and 
complex equation symbology, while enhancing NROFF -ME's 
capabilities, they add more categories and commands, and 
increase tne amount of time necessary for the user to see 
the actual results of commands, 

(3) The user manual for the NROFF packaae is no-t 
presented In sufficient detail to completely understand the 
effect, or use, of all commands. It appears that the user 
is supposed to have a basic understanding of the system 
before reading the manualsl 

(4) The command vocabulary is fairly large and they are 



not easy to remember. 


Based on 


oersonal use. 


only about 


twenty percent of the vo 


cabuiary is 


generally 


useful and 


therefore remembered. 


Table D,2 


oresents a 


simoilf led 


listing of tne most used 


commands . 







98 



Table D.2 - Basic Commands nROFF -ME 



1, Pace length 

2, Line spacing 

3, Line lengtn 

4, Page headers 

5, Indent 

- permanent 

- temporary 

6, Begin next page 

7, Need • lines 

8, Insert # blank lines 

9, Center tne next » lines 

10, Break 

11, Define a macro 

12, Flil/No-£lll 

13, Hyphenate/No-hyphenate 

14, Underline 

15, Section/Chapter headings 

16, Quotations 

17, Footnotes 

19, Keep an Index 

19, Start paragraph 

- basic 

- left adjusted 

- body indented 

- numbered 

20, Start display 

- list 

- clock 

- floating block 

- delayed text 

21, Table handler ♦ 

- definition 

- start 

- body 

- end 

22, Eouatlon definition 

23, Multiple column format 

24, Default paoer formats 

- thesis 

25, Control constructs 

« read sceclal variables 

- change special register 

- conditional formatting 



♦ part of Table preprocessor 
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APPENDIX E: DBASE II 



DBASE II Is a relational database system created by 
Ashton-Tate of Los Angeles, California for microcomputer 
systems. For this review, the CP/M version of DBASE II was 
used, where the DBASE II program is an executable "command 
file" residing In the system. 

The DBASE II system utilizes several different file 
types: database, report form, command, index, memory, and 
text. Each file type has a specific purpose that Is 
Identifiable by Its type name, "Report form" files store the 
Information, specified by the user, for describing the 
format (headings, fields, totals, subtotals, contents, etc,) 
In which a "database" file is to be output, "Command" flies 
contain a sequence of DBASE II statements, commands, and 
control structures necessary to create a user defined view. 
"Index" files are a list of pointers to a specific 
"database" file, "Memory" files contain tne values of 
memory variables and constants saved previously bv the user. 
"Text" files are collections of ASCII characters for input 
into a "database" file, or created by output from a 
"database" file, DBASE II cannot directly use "text" flies. 
Most of the files are stored In what is (cnown as Standard 
Data Format (SDF), and they can be used directly by any 
other program that uses SDF flies. Additionally, any text 
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files In SDF can be used by the DBASE II system. The file 
is the largest data object supported by DBASE II which 
creates, deletes, or modifies the current file(s), A 
database file is brought into reference by user 
specification, and a rnaximum of two database files can be 
"open" at one time, 

DBASE II can be used interactively or can be orogrammed 
to create a view of the database to support recurring 
applications. Regardless of method, DBASE II orovloes the 
user with the same basic high-level data definition (DDL) 



and data 


manipulation 


(DML) 


language , 


An Eng 


lish 


ll)ce 


command 


language with 


a 


very 


regular 


syntax 


is a 


user 


friendly 


feature of 


DBASE 


II 


, Tne 


commands 


are 


very 



powerful in that their operands and results are typically 
database files. The command structure is usually presented 
in the following form; 

COMMAND (SCOPE] [CONDITION] 

The scope modifier designates the number of records to 
be selected in response to the specific command. The 
condition modifier specifies a conditional statement that 
the record's field values must satisfy in order for the 
record to be included in the final result. Table E.l 
provides a listing of the basic DBASE li commands, with 
duplicate commands having been factored out, 

101 



Taole E,1 



DBASE II Basic Commands 



1, Display an expression on the screen 

2, Format screen or printer output 

3, Input a character strino 

4, Input a string to a memory variable 

5, wait for user input 

6, List the records in a database 

7, Disolay data from a database 

8, Disolay the structure of a database 

9, Rename a file 

10, Erase a file 

11, Generate a report 

12, Execute a "command" file 

13, Return from a "command" file 

14, Display the contents of the memory variables 

15, Store a value in a memory variable 

16, save memory variables to a file 

17, Restore memory variables from a file 

18, Select a specific dataoase for use 

19, Set specific DBASE II parameters 

20, Abort a command 



21, Create a new database 

22, Edit a database 

23, Modify a database's structure, or the 

contents of fields in selected records 

24, Update a database from another database 

25, Add data from a text file to a database 

26, Copy data from a database to a text file 

27, Insert record(s) into a database 

28, Delete recordCs) from a database 

29, UnmarK records marked for deletion 

30, Locate a record based on key value, 

or condition 

3t. Goto a specified record 

32, Move forward or backward in a database 

33. Index a database 

34. Sort a database based on a field 

35, Perform JOIN operation on two databases 



36. Count the number of records 

37, Sum a field or subfield in a database 
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Default ordering for records in a database file is the 



sequence in which the records are entered. Ordering can be 
altered by inserting records into specific parts of the 
database, and by sorting or indexing the database, in the 
default order, the "database" file does not contain a 
recognized key. 

By sorting or indexing a "database" file, keys are 
defined and the search tinse required to locate a record is 
reduced. Multiple Indexing be done for the same database, 
but based on different keys. Sorting produces a new 
"database" file, which is a copy of the original database, 
only it is sorted. An "Indexed" file is a virtual file of 
pointers to the original "database" file. Whereas lookup 
speed can be enhanced by indexing a database, there is 
overhead Incurred in maintenance of the "index" file. 
Changes made to the original database file are not reflected 
in the new sorted "database" or "index" file. The orioinai 
database must be sorted or indexed after each change in 
order to remain current. 

The data definition language allows tne user to define 
the oraanlzation of the data in a new database file oy 
specifying the name of the database, and giving information 
on each of its fields (name, type, width, decimal places). 
The structure of a new database file can also oe copied from 
that of another database file. Additionally, new structures 
can be created as the result of using the JOIN operator 
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provided by the DBASE II system. At any time, the structure 
and/or contents of a file can be displayed or output. The 
structure of a database file can also be modified at a later 
time, but presents some problems in that all records 
currently in the database file are destroyed. 

Besides usino DBASE II interactively, it can be 
programmed in its own language through the use of. ’’commahd” 
files, Tne statements are embedded in the file and 
iterative execution of DHL statements are controlled by a 
set of DBASE II control structures (If-Then, I£-Then-Eise , 
Goto, and Do-wnile), "Command" files tend to make extensive 
use of memory variables and Input/output functions which are 
also extensively supported by DBASE II. To create a user 
view the des tgner/oroarammer will edit a "command" fileCs) 
to contain the correct DBASE II statements, commands, and 
control structures to manipulate the oroper "database" 
files. The capabilities and limitations of any view is 
dependent on the desion of tne "command" £ile(s). 

The reason for the oreat popularity of DBASE II is that 
it is a very easy database management system to learn and 
use. Its English-like commahd lahguage is hatural and user 
friendly. Although the command set is rather extensive, the 
command names accurately describe their action and use a 
regular syntax so they are easy to rememoer. The 
interactive nature and full screen display orientation makes 
user interaction simple and direct. With Its set of 
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predefined functions, Input/output commands, ’’command" 
files, and programming constructs It Is easy to create views 
for almost any application, DBASE II Is a powerful 
relational database system yet it Is obvious that the 
designers gave much thought to keeping it simple and did not 
introduce complexity for its own sake. However, there are a 
couple of problems with DBASE II which are worth mentioning, 
and they are all probaoly due to the justiried emphasis on 
simplicity, 

(1) At any one time, a maximum of two databases can be 
in reference. This limitation requires that databases be 
explicitly brought into and out of use. It would help If 
there was another method, besides using a "command" file, 
for performing operations on multiple taoles, 

(2) In modifying the structure of a database the 
contents are deleted. This requires that the dataoase oe 
explicitly saved to an external database and then oe 
recopied back after structure modification. It is an 
inconvenience, to say the least, 

(3) Tne only relational operation directly provided by 
the system is the JOIN command. It would greatly enhance the 
capability of the system to provide more of tne operators. 

(4) The display structure is a little bit too rigid, 
and tne user does not nave much direct control, sort of 
writing a "command" file, to effect the output format. 



105 



APPENDIX F: SEQUITUR 



SEQUITUR Is a relational database system designed by the 
Pacific Software Manufacturing Company of BerXeley, 
California, 

SEQUITUR sees a database as a collection of named 
tables, each of which contains some Xlnd of data related to 
the subject of the database. Each dataoase has a set of 
system tables. The "Column” table lists the name, type, 
size, and display format of all columns authorized for use 
In the database's tables. The "Table" table lists the names 
of the columns that are included in each of the database's 
tables. Together the "Column" and "Table" tables act as 
part of a data dictionary system for the database, 

SEQUITUR has a fairly large command vocabulary of over 
sixty seven commands. There are twenty five basic commands, 
forty two screen editor commands, and more formed by 
combinations of the previous commands, A multilevel "Helo" 
facility is used to support the user, 

SEQUITUR offers four kinds of help. There are status 
lines at tne toe of the screen. An "edit card" display can 
be called by the user in order to see a comprehensive list 
of cursor object and motion keys, and escaoe operations. 
The "help" command summons an on-line manual, that is oreset 
by the user to provide no, medium, or maximum nelo. Lastly, 
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there are situational help promots that occur during 



the 



comirand process. 



Table F.l - SEQUITUR Basic Commands. 



1, CHOOSE {database) 

2, CREATE {database) 

3, ADD to {table) 

4, EDIT {table) 

5, SHOW {taole) 

6, PRINT {table) 

7, REPORT generator 
9, FORMS generator 

9. SELECT from {table) * 

10. MANUAL select 

11. JOIN {tables) 

12. SORT {tables) ♦ 

13. UNION ♦ 

14. INTERSECTION ♦ 



15. 


DIFFERE 


NCE 


* 


16. 


UNIQUE 


row 


s ^ 


17. 


DUPLICATE 


rows ^ 


18. 


COPY 






IP. 


APPEND 






20. 


REMOVE 


row 


s 


21. 


RENAME 


col 


c 

B 


22. 


COMPACT 


ba 


se 


23. 


DUMP to 


{f 


ile) 


24. 


LOAD fr 


om 


{file) 


25. 


HELP fr 


om 


manual 


26. 


EXIT 







♦ = Member of SEQUITUR's "set" commands. 



The twenty five basic commands 
operational capabilities of the 
commands are presented to the user in 



cover 
SEQUITUR 
the form 



the 

system 
of a 



major 
The 
menu , 
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and once a cnolce Is made SEQUITUR enters the display mode 
necessary to support that choice. Table F,1 lists the basic 
commands, plus the command for exiting from SEQUITUR, 

The SEQUITUR display modes are organized as "tables", or 
"pages". The table mode is similar to the approach taken by 
the "Ouery-by-Exatrple" system (QBE), and presents the data 
in columns and rows with vertical lines separatina the 
columns and Indicators for new rows. Alternatively, the 
page mode presents the data one row at a time, with the 
column headings listed vertically. The user has the ability 
to flip back and forth between the two display modes at 
will. 



Table ? ,2 - SEQUITUR Cursor Object & Motion Commands. 



1, Move cursor up one line 

2, Move cursor down one line 

3, Move cursor left one object 

4, Move cursor to next object 

5, Move cursor to bealnning of object 

6, Move cursor to previous word 

7, Move cursor to end of current object 
9, Move cursor to next word 

9 , Object = word 

10, Object = line 

11, Object = sentence 

12, Object = oaragraph 

13, Object = view 

14, Object s page or screen 

15, Object = column 

16, Object = row 

17, Object = one character 
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Once in a desired display mode the user must make use of 



the editor commands to make changes to the table. All editor 
commands are single ' keys combined with the <Control>, 
<Escape>, or <Tab> keys. Table F.2 provides a list of the 
cursor object and motion commands available. Most 
operations require two commands since the object must be 
specified first, and then the actual ooeration. 



Table F,3 - SEQUITUR Screen Editor Commands, 



1, Delete left portion of object 

2, Delete entire object 

3, Delete right portion of object 

4, Flips "insert" toggle 

5, Shows rows marked for deletion 

6, Flip "page-taole" display style 

7, Goto *-th object 

3, Goto last Object 

9, Restores more recent version of row 

10, Display earlier version of row 

11, Executes a command 

12, Search forward for column entry 

13, Search backwards for column entry 

14, Edit card display 



The screen editor commands are used to make actual 
changes Cadditlons, modifications, or deletions) to the 
displayed table on the screen. Table F,3 lists these 
commands which are used in conjunction with the cursor 
object and movement commands listed previously. 
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Additionally there are a number of miscellaneous 
commands that are provided to aid the user. These are listed 
in Table F,4, 



Table F,4 - Additional SEOUITUR Commands 



1, Get Edit Help 

2, Scroll Forward 

3, Scroll 0ac'<wards 

4, Interrupt Present Ooeration 

5, Loci</Unloc)c Cursor Object 



There are an abundance of table tyoes in SEQUITUR, 
’’Virtual" tables consist of oolnters to data in a "base” 
table(s), and are formed by conducting relational operations 
(e.q. JOIN) on the base table(s). Virtual taoles are 
permanent additions to the database. All operations 
conducted on the virtual table effect the base table, but 
not all operations on the base table win reflected in the 
virtual table, 

"Slice" tables consist of the data from a "home” taole, 
and are formed by restricting or rearranging the columns in 
the home table. Actually, slice tables are just alternate 
ways of viewing the same nome table. All operations 
conducted on the slice table effect the home table, and all 
operations on the home table effect the slice table. 
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"Template" tables are used to store control information 
on the operatlon(s) (SELECT, SORT, UNION, DUPLICATE, UNIQUE, 
INTERSECTION, and DIFFERENCE) desired to be performed on a 
set of "base" tables. The user specifies once the sequence 
of operations to be performed, and each time that result is 
desired the appropriate template table is called to create 
the desired virtual table. 

SEQUITUR provides several methods of outputtina data to 
the user; 

(1) There is the "print" command which promots the user 
to specify heading, page length, margins, page number, date, 
column/row divider symbol, etc, for either a "table" or 
"page" style output. The entire table is then output, one 
record at a time, in the specified format, 

(2) There is the "form generator". The user creates a 
form letter or document by making an entry in the "forms" 
table in either "page" or "taole" style, and answering 
several system prompts as to page size, width, margins. The 
form generator is intended for letter tyoe generation since 
it only allows one text field in the form. All other entries 
are pulled from an aopropriate table and the "form" reoeated 
for each row in that table. 

(3) There is the "report generator". The user creates a 
report table that is associated with a known data table. The 
report table specifies which data table columns are to be 
used, how they are positioned, what name tney have on the 
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form, allotted width, and alignment. Again, the user must 
specify formatting items liKe page length, line length, 
margins, delimiters, and other related items. The individual 
columns in the report table can be marked for sorting, 
grouping, and/or arithmetic processing. If arithmetic 
processing is opted for, then another table, the "function" 
table is created to record what is to be done to each column 
- total, minimum, maximum, average, or count. 

Based on a very short familiarization exoerience with 
SEQUITUP there is no doubt that it is a oowerful and 
complete relational DBMS, However, it is not as user 
friendly as its advertisements would lead you to believe. 
Some of the problems encountered were; 

Cl) Too many commands to remember. This increased 
learning time and added to the confusion. Too many of tne 
commands were just window dressing in that tneir effect 
could have oe done using other commands, (Like the "Object 
=", extra cursor movement and deletion commands.) wniie 
using keys as commands leads to faster command input, it 
makes things more difficult when tnere are so many commands 
the symbol on the key has little or no relation to its 
effect , 

(2) The structure of the user interface was unwieldy. It 
was easy to get lost and difficult to recover to a known 
location. Operations that worked under one condition did 
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not work in another 
unexpected results, ( 
cotpmand will return 
ignored or treated as 



(3) There were too 


tables, editing 


tabl 


tables. The user 


is be 


that is oetter 
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was created with 
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considerations to 
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, or produced completely different 
e,q, in some instances the "exec 
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APPENDIX G: VISICALC 



VISICALC Is an electronic spreadsheet program created by 
Software Arts, Inc, of Cambridge, Massachusetts and marketed 
by Personal Software Inc, of Sunnyvale, CA, Its purpose is 
to allow the user to easily model a wide range of numerical 
proDlems in a standard tabular format by replacing the 
user's pencil, calculator, and scratchpad. 

The screen is divided into a grid of columns and rows 
that form addressable (column, row) entry positions. The 
columns, which run across the top of the grid, are lettered 
starting with "A" and the rows, which run down the side, are 
numbered starting with "1", Each entry position is an 
independent entity, and can contain a character string, a 
numeric value, or a function that must oe calculated. Entry 
positions that contain functions are recalculated by 
VISICALC each time certain conditions are met. The functions 
will specify values in terms of constants, operators, and 
the values of other entry positions. 

The screen is used as a "window" into the spreadsheet 
and is modifiable by the user. The user is given numerous 
commands, see Table G,l, with which to alter the disolay 
format of the screen. 
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Table G.l 



VISICALC Display Commands 



1, Clear Spread Sheet 

2, set Global Display Format To; 

• Integer 

- Dollars & Cents 

- Left/Right Justified 

- Graph 

3, Set Entry Display Format To; 

- Integer 

- Collars & Cents 

- Left/Right Justified 

- Graph 

4, Reset Entry To Global Display Format 

5, Set Column width within A Window 

6, Set Order Of Recalculation; 

- Column wise 

- Row Wise 

7, Set Recalculation; 

- Automatic 

- Manual 



8. 


Move An Entire Row 


Or Column 


9. 


Window Control; 






- Split Screen Hor 


Izontal 




- Split Screen Ver 


tical 




- Single Window 




10. 


Window synchronizat 


Ion; 



- Synchronized 

- Unsynchronized 



The window can be "split" into two halves so as to looK 
into nonadjoining areas of the spread-sheet simultaneously. 
The two windows can be "svnchronlzea" so they move toaetner» 
or unsynchronized so movement is independent. Disolay 
format may be globally set for the screen as a whole, or 



individual entry 


positions can 


be assigned 


their own 


format , 


Column width is 


variable from 


3 to 37, out 


columns 


In the 
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same window must have the same width 



The value of each 



entry position is calculated by "column order" (Al, A2, ..*> 
An, 01, 32, ..., Bn, Cl, etc.) unless the user chances the 
recalculation order to "row order" (Ai, 01, ..., nl, A2, 02, 
n2, C2, etc.). By default VISICALC starts in 

"automatic" recalculation mode where the value of all entry 
positions are recalculated each time an entry is chanced. As 
this can significantly slow down the model wnen large grids 
and/or complicated numerical expressions are used, the user 
can enter "manual" recalculation mode where a command must 
be Issued to cause recalculation to occur. 

VISICALC provides a command-line oriented editor that 

r 

enters, modifies, or deletes data in a referenced entry 
positlon(s). A cursor is orovided on the grid to indicate 
the current entry position referenced by visiCALC. There 
are screen commands to allow the user to scroll across tne 
grid or to move to an exact (row, column) entry position. 
If needed, the numeric processing capability of VISICALC can 
be used lixe a calculator to support the user's 
computational needs. A powerful capability of visiCALC is 
the replicate command. This allows the user to define an 
entry once, and then have it entered in a ranee of 
successive column or row entry positions. Additionally, the 
user can specify if the original entry is to be replicated 
exactly, or should any references to other entry positions 
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be updated at each new position to ta><e into account 



relative position on the spreadsheet. 



Table G.2 - VISICALC Cursor ^overrent & Entry Commands, 



11, ^<ove Cursor Right Or Up 

12, Move Cursor Left Or Down 

13, Change Cursor Direction; 

- Up/Down 

- »icht/Left 

14, Move Cursor To Tne Other vlndow 

15, Move Cursor To A Specific Entry Position 



16, Abort Last Command 

17, Set An Entry Position To BlanK 

18, Delete An Entire Row Or Column 
1®, Inset A Mew Row Or Column 

20, Replicate An Entry 

21, Set Title Areas; 

- Horizontal Title 

- Vertical Title 

- Mo Title 

22, Repeat A liabel Entry 

23, '■’ake An Immediate Numerical Calculation 

24, Enter A Label In An Entry Position 

25, Enter A Value In An Entry Position 

26, Save A Cooy Of The Soread-Sheet 



Since VISICALC is a numerical modeling tool it has a 
series of arithmetic and agaregate functions that it 
supports. Table G,3 provides a listing, VISICALC has been 
designed to store numbers in decimal format# not blnarv, and 
maintains them with uo to eleven significant dlaits or 
decimal olaces. 
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Table G,3 - VISICALC Arithmetic & Aggregate Functions 



a. Addition 

b. Subtraction 

c. Multiplication 

d. Division 

e. Exponentiation 

£, Calculate The Sum Of A Range Of values 
g. Calculate The Minimum In A Ranoe Of Values 

n. Calculate The Maximum In A Range Of Values 
1, Count The Number Of Entries In A Lise 
j. Calculate The Average Of A Range Of Values 
K, Calculate The Net-Fresent-Vaiue Of A 
Ranoe Of Values 

l, Perform A Lookup Operation 

m, PI (3.1415926536) 

n, Calculate The Absolute Value 

o, Calculate The Integer Portion Of A Value 

p, souare Soot 

g. Logarithms, Base 2 

r. Logarithms, Base 10 

s. Trigonometric Functions (Sin, Cos, Tan, Asln, 

Acos, Atan) 



VISICALC makes use of dynamic memory allocation so the 
actual dimensions of the spread-sneet depend on the amount 
of memory available and tne complexity of the entries made 
by the user. The user does not have to worry about memory 
allocation since VISICALC takes responsibility for its use 
and efficiency. As entries shrink, or are deleted, VISICALC 
reclaims the extra memory space. The user is shown how much 
memory remains and a warning prompt occurs when memory space 
is nearly exhausted. 
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For a permanent copy of the contents of the spread sheet 
the user may send the outout to a printer, A suopart of the 
total spread-sheet may be sent by designating the lower 
right corner to be orinted, 

VISICALC is a powerful and fairly simple modeling tool 
whose advantages seem to easily outweigh the dlsadvantaaes . 
The command vocabulary is low C26 commands, 19 functions) 
and the greater majority are actually useful and not just 
window dressing. The user manual is well written and easily 
understood, but is fairly long, VISICALC supports a Known 
human weakness (small/fast short term memory, large/slow 
Iona term memory, and slow calculation speed) by remembering 
the details of a commonly reoccurring user broclem (the 
situation to be modeled), limiting the user to or'oviaing a 
smaller and more select set of initial inputs, ano 
performing the computations in a faster, more reliable, and 
repeatable manner. However it does have some proolems: 

(1) Command strings and their effect must be memorized 
since there is little relation to the strlno and the effect. 
Menus provided by the system are very poor, and reauire you 
to already Know the meaning of tne command string. 

(2) A oaslc understanding of VISICALC and a high degree 
of operational capability can be obtained, in a fairly short 
time, by reading only the first third of the user manual. 
However, to gain maximum use of the system requires a 
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significant amount of time and effort to read the entire 
user manual and experiment with the operations. Some nice to 
<now features that have a major effect on model validity 
(e,g, recalculation order) are discussed at the end of the 
user manual and might be easily missed. 
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APPENDIX H: ZIP 



The relational data base manaqement systetr "DBASE II" » 
described In Appendix (D), contains a set of commands which, 
when embedded in a "command" file, define the output format 
used to generate the display on the screen, or output to the 
printer. In addition to generating the display form, the 
commands also direct the DBASE II system to either determine 
the values of the entries from a record in the referenced 
database, or from memory variables. It the Inout device is 
the screen/Keyboard , DBASE II may retrieve a user entered 
value from tne screen and store it in a field of a dataoase 
record, or in a memory variable. These form definition 
commands can also be put into a new type of file, the 
"format" file, by ZIP, In this case the format, contained 
in the "format" file, is used as an display overlay to 
prompt the user to chanoe data values in an existing record 
in a "database" file, 

ZIP is a CP/M program used to generate, or modify, a 
DBASE II "command" or "format" file. It is a oowerful tool 
in the sense that the user is not required to Know tne 
details of the DBASE II form generation capability 
("command" files, and display commands), ZIP presents the 
user with a blank screen and an on-screen editor, whicn 
supports several levels of cursor movement and formatting 
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commands, to help in the form design. Table H,l lists the 
ZIP editor commands. 



Table H,1 - ZIP Editor Commands, 



1 . 



2 . 

3 . 

4 . 

5 . 



6 . 

7 . 

9 . 

9 . 

10 



11 



Screen commands 

- top 

- bottom 

- next 

- previous 

- first 

- last 

Middle of line 
Insert a space 
Add a line 
Delete 

- character 

- line 

Draw/Erase horizontal line 
Draw/Erase vertical line 
Erase/Save worK file 
Insert DBASE II command expression 
, Change variable 

- vertical marker 

- horizontal marker 

- tab spacing 

- margin 

- cage length 
, Quit 



The cursor can be moved to any oosiCion on the blank screen 
where the user will enter the information reauired by the 
ZIP program. Information is conveniently limited to literal 
strings, memory variables, record field values, and fetching 
a value from the screen and storing it into a record field 
or memory variable,- Interspersed oetween these ZIP 
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formatting commands may be DBASE II executable commands if 
the file type is "command". There are special purpose 
commands to draw# or undraw, vertical and horizontal lines 
on the form. 

The ZIP program may be viewed as a translator between 
the screen design made by the user and the ooerations of 
DBASE II, The screen contents associated with each screen 
position are translated into a sequence of DBASE II 
commands, statements, and control structures v/nich are 
organized as either a "command" or "format" file. ZIP also 
places any embedded execution commands into the file and 
automatically sets, or resets, tne aopropriate system 
"toggles" as needed, 

ZIP is a useful support tool for DBASE ll in that it 
relieves the user from having to orogram a "com'^and" file in 
order to create a desired display format. However, it must 
oe pointed out that ZIP is a very basic formatter, is line 
oriented, and is incaoable of the more complex types of 
displays . 
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APPENDIX I: MAIL- 



"MAIL" Is an electronic mall facility produced by tne 
University of California at Berkeley and Bell Laboratories 
for the UNIX operating system. It allows users to send 
messaaes to other users, or groups of users, on the system. 

The basic unit of the MAIL system is the message, which 
Is simoly a special type of text file. The message is 

preforraatted and contains fields for originator, 

destination, subject, copy to, and body. Messages are 

contained either In the users "private" mailbox or in the 
"system" mailbox, A "dead-letter" file is also maintained 
for each user to contain messages which cannot be delivered 
to a valid destination. Tne private mailoox and dead-letter 
file are maintained as text files in tne UNIX directory and 
therefore can be used bv other orograms running under UNIX, 
Upon logging into the UNIX system, a promct apoears at 
the terminal indicating that there is mail for the user. 
Messages addressed to a user are initially contained In the 
system mailbox, and can be read from the system mailbox oy 
the MAIL facility. The messages already in the private 
mailbox and/or dead-letter file are text files anc thus not 
directly accessible to the mail facility. 

The user may elect to read the mail by invoking tne mail 
facility, A one line summary of all messages in the system 
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!nallbox Is presented to the user^ and each message is given 
an integer identification number starting at one. At this 
point the user has a number of different options available 
as summarized in Table l.l. 



Table 1.1 - MAIL Command Summary 



1, Allas a name + 

2, Unalias a name(s) 

3, Goto previous message ♦ + 

4, Goto next message ♦ + 

5, Display summary of commands + 

6, Display out all currently defined aliases 

7, Display a message 

8, Display out headers of message list t 

9, Display message list 

10, Display size of each message 

11, Display top few lines of each message 

12, Execute the following UNIX shell command 

13, Change directory 

14, Delete message(s) + 

15, Delete current message, print next message 

16, Undelete messages marKed for deletion 

17, Reply to a received message * 

18, Edit a list of messages in turn 

19, Send message to designated users + 

20, £nd-of-message + 

21, Exit, don't Change system mailbox * 

22, Quit, save undeleted or unsaved messages in the 

user's mailbox, save unreferenced in the 
system mailbox, 

23, MarK message(s) to be saved in system mailbox * 

24, Save a message list by appending to a text file * 

25, List current range of message headers 

26, Help + 

27, Set ootlons + 

28, Unset options 



♦ mail facility has more than one command to 
perform this action. 
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The user may select a message and read it. 



After 



reviewing the message the user may forget the message, save 
It In the system mailbox, delete It, or prepare a response. 
When the user quits the MAIL facility all messages which 
have not been deleted, saved, or reviewed are placed bacic 
into the system mailbox. The remaining messages, those 
reviewed but no special action indicated, are placed in the 
private mailbox. If the user desires, the MAIL facility can 
be exited and the system mailbox left unchanged. 
Additionally the . user can create "alias'* names tnat 
correspond to multiple users, ask for message summaries, 
append messages to files, or invoke an editor. 

The MAIL utility does not contain its own editor, but 
depends on the edltorCs) available to the Unix system and on 
the user to set an option specifying which one is desired. 
When the user indicates that a message is to be created, the 
editor is invoked, the user enters the text, ana when 
finished issues an end-of-message command to return control 
to the MAIL facility, while in the editor, the user can 
issue "escape" commands that directly effect the message 
processing, A listing of these escape commands is provided 
In Table 1,2, Contents of otner files may be inserted into 
the messaoe, names of recipients added or changed, the 
header field edited, or an alternate editor invoked. 
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Table 1,2 - MAIL escape commands 



1, Execute UNIX shell command 

2, Add names to recipients of copy 

3, Read •‘deadletter” file into message 

4, Invoke text editor 

5, Aoort the message being sent 

6, Insert a named file into the message + 

7, Create a subject field 

8, Write the message into a named file 

9, Pipe the message through a process as a filter 

10, Insert a string into the message 



While in the MAIL facility, UNIX shell commands may be 
Issued, The MAIL facility is temporarily interrupted, tne 
command is executed, and then the MAIL facility is resumed 
without adverse effect. 



Table 1,3 - MAIL obtions. 



1, C Append/Prepended) messages to private mailbox 

2, (Yes/No) Subject line prompt 

3, (Yes/No) Prompt for carbon copy recipients of message 

4, CYes/No) Modify delete command 

5, (Yes/No) lanore terminal Interrupt signals 

6, (Yes/No) Include sender in group message recipients 

7, (Yes/No) Saving interrupted messages 
fi. Define default editor name 

9, Define escape character 

10, Define file to record outgoing mail 

11, Define number of lines in the "too" of a message 
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Additionally, the MAIL facility has a series of options 
the user can change to tailor its operation. Table 1.3 
provides a listing of these options. 

The MAIL facility is a good support program and is quite 
capable of accomplishing its goals. However, it has more 
than its fair share of problems. 

(1) There is a very limited user manual, and experience 
must be gained from other users or by trial and error, 

(2) There are too many commands, and too many of those 
duplicate each other. The number of commonly useful 
commands is low (marKed with a +), with the rest being 
window-dressing, 

(3) The facility is not user friendly. The user must oe 
aware of location in the facility and what is exoected next, 
because there are no special prompts and the help command 
only provides a command summary, 

(4) If the message recipient is on line when the message 
arrives, whatever operation is in progress is rudely 
interrupted oy the display of the message. This can be very 
disconcerting to the recipient. 

(5) The user can't determine which message is going 
where (system mailbox, private mailbox, dead-letter file), 
prior to leaving the mail facility. 
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